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1.   INTRODUCTION 

1.1.   Introduction  of  Research — Continuous  Network  Simulation  Languages 

The  research  on  which  this  thesis  is  based  was  undertaken  as  part 
of  the  development  of  a  general  purpose  package  for  digital  simulation  of 
continuous  systems  based  on  ordinary  differential  equations.   The  overall 
structure  of  the  package  which  has  been  developed  is  outlined  in  Figure  1.1. 
In  particular,  this  thesis  is  concerned  with  continuous  simulation  modeling 
languages  and  with  the  design  and  development  of  MODEL,  a  'universal' 
language  for  continuous  network  simulation,  for  use  within  this  package. 
Thus,  we  will  be  concerned  primarily  with  the  processes  of  Figure  1.1a — 
that  is,  with  the  language  features  which  support  the  formulation  of 
continuous  system  models.   We  will  concern  ourselves  with  the  implementations 
of  the  modeling  support,  model  analysis,  and  integration  processes  only  to 
the  extent  that  these  implementations  facilitate  or  encumber  the  provision 
of  desirable  modeling  language  features. 

Our  research  efforts  were  guided  by  both  short-range  and  long- 
range  goals.  Our  short-range  goal  was  to  produce  and  distribute  a  widely 
applicable  and  easy-to-use  language  for  continuous  network  simulation,  to 
the  long-range  end  of  furthering  the  study  of  languages  for  simulation  in 
the  physical  sciences.  By  distributing  the  language  to  a  number  of 
installations  where  different  types  of  continuous  simulation  problems  are 
being  studied,  we  will  be  able  to  measure  the  utility  of  various  language 
features  within  the  context  of  this  class  of  problems. 

These  primary  goals  led  us  to  a  set  of  secondary  short-range 
objectives  for  the  language  to  be  developed.   Our  desire  for  a  language 
which  is  widely  applicable  and  easy  to  use  implies  that  the  language 
should  be  flexible  enough  to  accommodate  very  complex  networks,  yet  require 
little  sophistication  for  simple  problems.   Thus,  the  language  should 
support  different  levels  of  problem  and  user  sophistication.   The  desire 
to  facilitate  the  modeling  of  complex  networks  led  us  to  desire  to  support 
hierarchical  models  conveniently,  since  most  physical  systems  are  naturally 
hierarchical — that  is,  they  can  be  described  at  a  series  of  levels  of 
increasing  complexity.   To  facilitate  distribution  of  the  language  to  a 
number  of  installations  having  potentially  different  hardware  and  operating 
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environments  we  further  sought  portability  in  the  implementation  of  the 
language  and  flexibility  in  the  model  execution  environment. 

The  discussion  of  features  of  the  MODEL  language  and  their 
motivations  will  be  continued  at  length  in  Chapter  3.   In  the  remainder 
of  this  chapter,  we  will  define  the  area  of  digital  continuous  simulation 
and  present  a  sample  network  which  might  be  modeled  for  continuous 
simulation.   Chapter  2  presents  a  survey  of  existing  continuous  simulation 
languages.   Chapter  4  offers  some  conclusions  concerning  the  present 
implementation  of  MODEL  and  prospects  for  its  further  development. 

1.2 .   Definition  of  Digital  Continuous  Simulation 

Simulation  has  been  broadly  defined  in  [1]  as  "the  development 
and  use  of  models  for  the  study  of  the  dynamics  of  existing  or  hypothesized 
systems."  This  close  relationship  between  simulation  and  system  modeling 
is  a  very  important  concept.   The  various  well-established  simulation 
methodologies — continuous,  discrete,  digital,  and  analog — are  in  fact 
distinguished  by  differences  in  the  types  of  models  which  they  employ  and 
resulting  differences  in  the  methods  used  to  trace  model  behavior,  rather 
than  by  inherent  differences  in  the  physical  systems  to  be  simulated. 
In  general  the  purpose  of  the  study  determines  which  aspects  of  the 
physical  system  are  to  be  modeled.   This  in  turn  has  a  major  influence 
on  the  selection  of  a  methodology  for  the  study.   Additional  considerations 
involved  in  selecting  a  methodology  frequently  include  the  desired  accuracy 
and  repeatability  of  the  simulation,  the  allowable  running  time,  and  the 
ease  of  modeling. 

In  the  remainder  of  this  section,  we  will  distinguish  digital 
continuous  simulation  from  the  other  well-established  simulation  methodologies, 
namely  discrete  simulation  and  analog  simulation. 

1.2.1   Continuous/Discrete  Digital  Simulation 

There  exist  two  basically  different  digital  simulation  methodologies — 
continuous  and  discrete.   Continuous  simulation  is  characterized  by  models  in 
which  response  phenomena  occur  continuously  and  in  parallel  as  a  function  of  one 
or  more  independent  variables.   System  states  are  modeled  by  a  set  of  real- 
valued  dependent  variables  and  responses  are  modeled  by  a  simultaneous  set  of 


differential  and  nondif ferential  equations  in  these  varibles.   The  behavior 
of  a  model  is  traced  by  a  numerical  approximation  to  the  integral  of  the 
set  of  equations.   Typical  applications  of  continuous  simulation  are  to 
systems  modeled  as  initial  value  problems  in  ordinary  differential  and 
nondif ferential  equations  with  time  as  the  independent  variable.   Steady- 
state  models  and  models  involving  multiple  independent  variables  are  less 
frequently  simulated  with  general  purpose  packages  because  automatic 
techniques  for  the  solutions  of  the  boundary  value  problems  and  systems  of 
partial  differential  equations  posed  by  these  models  are  less  well-developed 
than  those  for  initial  value  problems  in  ordinary  differential  equations. 
Applications  of  continuous  simulation  arise  most  frequently  from  engineering 
problems  in  the  physical  sciences — for  example,  in  the  analysis  of  electrical, 
mechanical,  and  structural  networks.   Other  applications  include  economic  and 
population  dynamics  models. 

Discrete  simulation  is  characterized  by  models  in  which  response 
phenomena  occur  as  a  sequence  of  events  or  interactions  at  discrete  points 
in  the  independent  variable  (nominally  time).   System  states  are  modeled  by 
a  set  of  entities  having  certain  attributes  and  by  a  set  of  files  or 
processes  in  which  these  entities  reside.   Responses  are  modeled  by 
procedural  events  which  alter  the  system  state  by  creating  or  destroying 
entities,  changing  their  attributes  or  the  files  in  which  they  reside,  and 
scheduling  future  events.   The  behavior  of  a  model  is  traced  by  the  use  of 
an  event  schedule  which  controls  the  execution  of  scheduled  events  and  the 
updating  of  simulated  time  to  the  point  at  which  the  next  event  is 
scheduled  to  occur.   Typical  applications  of  discrete  simulation  are  to 
systems  modeled  as  a  sequence  of  probabilistically  interdependent  steps  or 
events.   These  applications  arise  most  frequently  from  problems  in  operations 
research  and  gaming — for  example,  in  analyses  of  multi-task  job  shop, 
corporate,  and  military  strategies  in  which  attention  is  focused  on 
individual  events  rather  than  on  average  or  aggregate  behavior. 

Distinct   continuous  and  discrete  methodologies  for  digital 
simulation  have  arisen  primarily  from  differences  in  the  aspects  of 
physical  systems  on  which  attention  is  to  be  focused  rather  than  from 
inherent  differences  in  physical  systems  themselves.   It  can  be 


said  that  a  continuous  model  represents  the  aggregate  or  average  of  some 
discrete  model  and  a  discrete  model  represents  a  sampling  or  microscopic 
view  of  some  continuous  model.   One  could  argue  that  all  physical  systems 
are  discrete  at  the  atomic  level.   However,  modeling  at  the  atomic  level 
is  frequently  impractical.   In  these  cases  continuous  simulation  can  be 
employed.   For  example,  population  dynamics  could  be  modeled  by  tracing 
individual  births  and  deaths  in  a  discrete  simulation.   However,  for  large 
populations  this  would  be  impractical  and  an  aggregated  continuous  model 
using  differential  equations  would  be  more  useful. 

A  system  which  is  modeled  best  with  discrete  methods  for  some 
studies  may  be  modeled  best  with  continuous  methods  for  other  studies 
which  have  different  purposes.   For  example,  discrete  simulation  is 
frequently  applied  to  corporate  systems  for  the  purpose  of  predicting 
the  short  range  effect  of  corporate  policies  within  an  environment  which 
can  be  predicted  in  a  probabilistic  fashion  at  best.   However,  continuous 
simulation  can  be  more  useful  for  corporate  studies  which  focus  on  the 
long-range  effect  of  policies  on  performance  in  stable  environments.   In 
such  a  study  reported  by  Smith  and  Waltz  in  [2],  a  series  of  continuous, 
deterministic  environments  and  an  algebraic  formulation  of  the  management 
policies  allowed  the  system  to  be  modeled  most  profitably  with  continuous 
methods . 

When  the  numerical  methods  used  to  approximate  the  integration  of 
differential  equations  are  considered,  the  distinction  between  continuous 
and  discrete  methodologies  becomes  somewhat  less  clear.   Digital  computers 
are  inherently  discrete.   Consequently,  these  methods  are  discrete, 
approximating  solutions  at  a  series  of  discrete  points  in  the  independent 
variable.   However,  the  classification  'continuous'  is  appropriate  when 
the  model  is  continuous  and  discretization  is  carried  out  automatically. 
On  the  other  hand,  the  classification  'discrete'  applies  to  finite 
difference  models  even  though  finite  difference  equations  are  a  crude 
means  of  approximating  the  integration  of  differential  equations.   This 
further  supports  the  contention  that  discrete  models  represent  samplings 
of  continuous  models  and  continuous  models  represent  aggregations  of 
discrete  models. 


In  the  remainder  of  this  thesis  we  will  restrict  our  attention  to 
continuous  simulation.   However,  many  systems  which  are  best  modeled  in  a 
primarily  continuous  fashion  (such  as  an  electrical  network)  include  some 
discrete  responses  (such  as  capacitor  ionization).   Thus,  a  widely 
applicable  continuous  simulation  package  must  include  some  facilities  for 
modeling  discrete  responses. 

1.2.2.   Digital/Analog  Continuous  Simulation 

Both  digital  and  analog  methodologies  have  been  widely  employed 
for  continuous  simulation  studies.   In  the  past  two  decades,  the  major 
emphasis  of  continuous  simulation  has  shifted  from  analog  to  digital 
methods  for  a  number  of  reasons.   We  now  turn  to  a  discussion  of  the 
relative  merits  of  analog  and  digital  methods  before  restricting  our 
attention  to  digital  continuous  simulation. 

Analog  simulation  involves  modeling  a  system  by  physical 
analogues  whose  behavior  mimics  that  of  the  system  to  be  studied.   The 
behavior  of  the  system  is  traced  by  observation  of  the  physical  model  over 
real  time.   The  nature  of  physical  models  at  the  level  at  which  they  can 
be  conveniently  monitored  is  predominantly  continuous.   Thus,  analog 
simulation  has  been  developed  as  a  methodology  for  continuous  simulation. 
Examples  of  analog  simulation  studies  include  the  use  of  scale  models  and 
wind  tunnels  in  aerodynamic  analysis,  the  use  of  structural  scale  models 
in  earthquake  analysis,  and  the  use  of  liquid  models  in  gas  flow  analysis. 
However,  in  the  remainder  of  this  section,  we  will  restrict  our  attention 
to  analog  simulations  in  which  physical  systems  are  modeled  by  dc  electrical 
analogues.   This  is  the  only  general  purpose  methodology  for  analog 
simulation  developed  to  date,  and  by  far  the  most  common. 

In  electrical  analog  simulation,  the  magnitudes  of  dependent 
problem  variables  are  represented  by  voltages.   Operations  on  these 
variables  are  implemented  via  electrical  analogues  such  as  integrators, 
adders,  multipliers,  dividers,  and  other  function  generators.   By 
appropriately  wiring  the  inputs  and  outputs  of  selected  analogues,  the 
user  can  construct  a  circuit  which  represents  a  simultaneous  set  of 
differential  and  nondif f erential  equations — that  is,  a  continuous  model. 
The  set  of  equations  can  then  be  integrated  by  the  continuous  operation  of 
the  analog  circuit  in  real  time. 


General  purpose  dc  analog  computers  became  available  soon  after 
World  War  II.   Their  ability  to  represent  and  solve  models  based  on 
ordinary  differential  equations  led  to  their  widespread  use  for  continuous 
simulation.   In  addition  to  the  essential  ability  to  model  differential 
equations,  electrical  analogues  are  well  suited  for  continuous  simulation 
in  that : 

1.  their  nature  of  operation  is  both  continuous  and  parallel; 

2.  the  speed  of  solution  is  fast  and  independent  of  the 
problem's  complexity;  and 

3.  they  allow  the  convenience  of  immediate  access  to  results. 
Analog  simulation  does  have  its  drawbacks,  however.   Complex 

networks  of  analogues  and  tedious  patchboard  wirings  are  required  to 
represent  sophisticated  differential  systems.   Other  major  problems 
concern  the  scaling  of  variables  and  the  accuracy  of  the  solution. 

For  a  lOOv  analog  computer  all  voltages  must  remain  within  the 
range  of  -lOOv  to  +100v.   If  a  variable  exceeds  the  maximum  voltage,  the 
corresponding  amplifier  becomes  saturated  and  the  solution  becomes 
erroneous.   Thus,  all  variables  must  be  scaled  so  that  none  exceeds  the 
maximum  voltage  during  the  simulation.   This  can  be  a  tedious  task  since 
a  large  model  will  include  many  variables  and  one  does  not  normally  know 
the  maximum  values  they  will  attain.   Furthermore,  voltages  cannot  be 
allowed  to  remain  too  small  or  noise  will  become  a  problem. 

The  accuracy  of  an  analog  simulation  depends  on  the  accuracies 
of  the  analogues  employed.   The  accuracies  of  electrical  analogues 
typically  vary  from  .005  to  .03  of  full  scale.   Because  of  limitations  on 
component  accuracies  an  accuracy  of  1%  for  a  simulation  of  modest 
complexity  is  considered  excellent.   Consideration  for  the  accuracy  of  the 
simulation  also  imposes  a  limit  on  the  maximum  running  time  permissible 
in  an  analog  simulation. 

On  first  comparison  with  analog  computers,  the  discrete 
procedural  operation  of  digital  computers  makes  them  appear  ill-suited 
for  continuous  simulation.   A  complex  numerical  integration  procedure  is 
required  to  trace  the  behavior  of  the  model.   This  generally  represents 
a  programming  effort  which  is  too  large  to  be  cost-productive  for  a  single 
simulation  study.   Furthermore,  these  digital  procedures  require  greater 


running  time  than  do  analog  simulations  and  their  running  time  is  very  much 
dependent  on  the  complexity  of  the  model.   However,  the  use  of  a  digital 
simulation  package  featuring  automatic  integration  accrues  many  advantages 
for  the  user.   Principal  among  these  are: 

1.  the  power  and  flexibility  of  digital  computers  for 
language  interpretation  allows  models  to  be  formulated 
at  a  much  higher  level  than  patchboard  wiring; 

2.  the  coding  of  problems  which  involve  discrete  responses 
or  logic  is  much  simpler  than  with  analog  methods  which 
require  the  use  of  relays  and  threshold  gates; 

3.  digital  simulations  are  more  easily  interfaced  to 

complex  procedures  for  such  things  as  parameter 

.2 
optimization; 

4.  digital  integration  using  floating  point  arithmetic  can 
achieve  much  greater  accuracy  than  can  analog  computers; 

5.  the  scaling  problem  of  analog  simulation  is  eliminated. 
Digital  floating  point  arithmetic  can  represent  both 
extremely  large  and  extremely  small  quantities  accurately; 

6.  digital  computers  can  supply  a  wider  variety  of  mathematical 
functions  than  can  analogues; 

7.  maintenance  of  digital  simulation  models  is  easier  than 
maintenance  of  an  analog  circuit.  Periodic  calibration 
and  accuracy  tests  are  not  required; 

8.  digital  simulation  allows  more  rapid  switching  from  one 
model  to  another  than  does  analog  simulation; 

9.  storing  a  digital  simulation  model  is  easier  than  storing 
an  analog  circuit; 

10.   the  user  is  free  to  concentrate  on  his  problem,  rather 
than  on  analog  intricacies. 
Thus,  although  digital  simulation  was  originally  used  only  to 
generate  check  solutions  for  analog  simulations,  by  1964  Brennan  and 
Linebarger  [4]  were  observing  that  "The  transcendance  of  digital  computers 
for  simulation  is  inevitable...."  By  1969  a  number  of  good  packages  for 
digital  simulation  were  available  and  Brandin  and  Schram  observed  in  [5]  that 
"a  significant  number  of  models  associated  with  differential  equations  are 
being  simulated  exclusively  and  preferentially  on  digital  computers." 


The  present  trend  is  toward  digital  continuous  simulation  using 
languages  which  are  continually  increasing  in  power  and  flexibility.   The 
advantage  of  using  an  analog  computer  is  restricted  to  problems  which  require 
the  excellent  frequency  response  of  analog  simulation  such  as  real  time 
applications. 

1.3.   Sample  Network  Problem 

Many  areas  of  systems  study  lead  to  continuous  models  which  pose 
initial  value  problems  in  ordinary  differential  equations.   Among  these  are 
electrical,  mechanical,  structural,  and  fluid  system  studies.   Many  such 
studies  can  be  conducted  most  conveniently  via  network   models — that  is,  via 
models  which  consist  of  a  number  of  elements  with  'defined'  or  'well- 
understood'  properties,  inter-connected  in  a  manner  which  could  be  original 
and/or  subject  to  change  during  the  design  process.   The  'well-understood' 
properties  of  the  network  elements  are  specified  by  sets  of  equations 
involving  a  variety  of  types  of  variables  and  parameters  while  the  connective 
properties  of  the  network  are  specified  by  generalized  application  of  Kirchoff's 
laws.   For  such  models  a  network  simulation  language  such  as  the  ECAP-II 
language  for  electrical  circuit  analysis  [6]  offers  the  convenience  of  macro- 
like invocation  of  network  elements,  high-level  alteration  of  network 
interconnections  during  the  design  process,  and  automatic  generation  of  the 
connective  equations  arising  from  the  application  of  Kirchoff's  laws  to  the 
nodes  of  the  network. 

The  principal  drawback  of  existing  network  simulation  languages  is 
that  they  have  been  designed  for  limited  classes  of  applications.   Connections 
in  these  languages  transmit  variables  which  are  natural  only  for  the  intended 
discipline.   For  example,  connections  in  electrical  network  languages  transmit 
single  voltages  and  currents  while  connections  in  a  structural  network 
language  might  transmit  six  components  of  displacement  and  six  components  of 
force.   Application  of  these  languages  to  a  different  discipline  requires 
extensive  user  effort  either  in  rewriting  the  language  translator  to 
accommodate  the  model  or  in  reformulating  the  model  into  the  existing  language. 
Furthermore,  these  languages  lack  facilities  for  conveniently  modeling  general 
network  elements  via  equations.   Typically,  these  languages  provide  a  fixed 
set  of  elements  which  can  be  extended  only  be  defining  new  elements  in  terms 
of  equivalent  circuits  constructed  from  the  basic  elements. 

Overcoming  these  drawbacks,  as  implied  by  our  goal  of  producing  a 
widely  applicable  language  for  continuous  network  simulation,  will  be  the 
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subject  of  further  discussion  in  Chapter  3.   In  the  remainder  of  this  section, 
we  will  illustrate  some  of  the  principles  of  continuous  network  modeling  by 
describing  a  sample  problem  from  this  area.   The  system  to  be  considered  is 
a  fluid  network  consisting  of  interconnected  reservoirs,  pipes,  sources,  and 
drains.   The  formulation  of  a  model  for  such  a  network  in  the  MODEL  language  i; 
shown  in  Appendix  B,  along  with  selected  portions  of  the  output  produced  by 
the  compilation  of  this  model. 

The  purpose  of  this  hypothetical  study  is  to  analyze  the  behavior 
of  a  proposed  storm  sewer  system  under  various  driving  functions  representing 
rainfall  to  determine  whether  the  rainfall  can  be  accommodated  without 
flooding  the  streets.   The  nature  of  the  problem  suggests  a  continuous 
methodology  using  the  idealized  Bernoulli  equations  of  fluid  mechanics 
which  state  that  the  quantity 

V2/2G  +  P/GAMMA  +  H 
remains  invariant  along  any  flow  line  in  a  steady  flow  situation.   The 
variables  in  this  quantity  are: 

G   the  acceleration  due  to  gravity,  a  constant  throughout 
the  system; 

GAMMA   the  density  of  the  fluid,  a  constant  throughout 
the  system; 

V   the  fluid  velocity  at  the  point  in  question; 

P   the  fluid  pressure  at  the  point  in  question  (above 
one  atmosphere) ; 

H   the  height  of  the  point  in  question  (above  some 
reference  point) . 
The  Bernoulli  equations  represent  an  idealization  of  the  physical  system 
since  they  do  not  model  head  loss  along  the  flow  lines.   We  employ  this 
idealization  for  the  sake  of  simplicity  only.   The  head  loss  could  be 
modeled  if  desired. 

To  accomplish  this  study  a  network  model  linking  four  types  of 
fluid  elements — sources  (rainfall),  reservoirs  (sewer  basins),  pipes,  and 
sinks  (drains) — is  desired.   The  properties  of  these  elements  are  well- 
understood  and  can  be  modeled  as  described  below.   The  behavior  of  inter- 
connections between  these  elements  is  also  well-understood  and  can  be 
modeled  by  the  respective  application  of  Kirchoff's  current  and  voltage 
laws  to  the  fluid  flow  and  to  the  Bernoulli  quantity  at  each  node  of  the 
network.   These  laws  state  that  fluid  does  not  accumulate  in  any  node  and  that 
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the  Bernoulli  quantity  assumes  the  same  value  at  all  points  connected  in  a 
common  node.   Since  the  functional  description  of  a  node  remains  the  same 
regardless  of  the  number  or  type  of  elements  connected  to  it,  and  since 
specific  interconnections  are  likely  to  be  changed  during  the  design  process, 
it  would  be  very  convenient  to  employ  a  modeling  language  which  can  handle 
these  connective  properties  automatically.   In  the  following  discussion,  we 
will  assume  automatic  handling  of  node  equations  and  will  not  model  these 
properties  explicitly. 

Source  Element 


This  element  represents  the  entry  of  rainfall  into  the  sewer 
network  at  a  storm  drain.   It  might  be  represented  graphically  as  shown 
in  Figure  1.2a.   The  element  model  consists  of  one  connection  point,  or 
terminal  which  is  labeled  by  the  integer  1  and  the  equation 

-FLOW  =  F(TIME) 

3 
where  -FLOW   represents  the  rate  of  flow  out  of  this  element  (i.e.,  the 

rate  of  rainfall)  and  F  is  some  function  of  time  which  describes  this  rate, 

The  value  of  the  Bernoulli  quantity  at  the  source  terminal  is  not  of 

interest  and  thus  is  not  modeled  explicitly. 

Reservoir  Element 

This  element  represents  a  storm  sewer  basin.   It  might  be 
represented  graphically  as  shown  in  Figure  1.2b.   The  reservoir  has  three 
connection  points.   Terminal  0  represents  the  point  of  connection  to  a 
source  element,  and  terminals  1  and  2  represent  points  of  connection  to 
other  reservoirs  or  to  fluid  sinks.   In  addition  to  the  values  of  FLOW 
and  B,  the  Bernoulli  quantity,  at  each  terminal  the  following  quantities 
are  used  in  modeling  the  reservoir: 

HS   the  height  of  the  reservoir's  surface 

AS  the  area  of  the  reservoir's  surface 

A   the  area  of  the  outlet  at  terminal  1 


H1  the  height  of  the  outlet  at  terminal  1 

P..  the  pressure  of  the  fluid  at  terminal  1 

V  the  velocity  of  the  fluid  at  terminal  1 

A„  the  area  of  the  outlet  at  terminal  2 

H~  the  height  of  the  outlet  at  terminal  2 

P  the  pressure  of  the  fluid  at  terminal  2 

V„  the  velocity  of  the  fluid  at  terminal  2 
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The  areas  and  heights,  except  for  HS,  are  assumed  to  be  parameters 
of  the  element.   This  parameterization  allows  the  same  basic  reservoir  element 
to  be  used  throughout  the  network.   HS  and  the  fluid  pressures  and  velocities 
are  local  variables  of  this  element.   HS  is  the  crucial  variable  since  its 
value  determines  whether  or  not  the  sewer  backs  up  into  the  street.   When  the 
reservoir  element  is  used  in  a  network,  an  initial  value  will  be  specified 
for  HS.   This  represents  the  height  of  the  fluid  in  the  reservoir  prior  to 
the  rainfall.   For  the  sake  of  simplicity  we  assume  that  the  initial  level 
of  fluid  in  the  reservoir  will  cover  the  outlets  at  terminals  1  and  2.   This 
allows  the  definition  of  the  reservoir  element  to  be  completed  by  the 
equations: 

1.  HS'*AS=FLOW  +  FLOW  +  FLOW 

2.  Vx  =  -FLOW1/A 

3.  V2  =  -FLOW2/A2 

4.  B  =  V  2/(2*G)  +  P  /GAMMA  +  H 

5.  B2  =  V22/(2*G)  +  P2/GAMMA  +  H2 

6.  B   =  HS 

7.  B   =  HS 

Equation  1  relates  the  rate  of  change  in  the  height  of  the  reservoir's 
surface,  HS',  to  the  rates  of  flow  into  the  three  terminals.   Equations 
2  and  3  define  the  fluid  velocities  directed  out  of  the  reservoir  at 
terminals  1  and  2.   Equations  4  and  5  relate  the  Bernoulli  quantities  B 
and  B„  to  fluid  velocity,  pressure,  and  height.   Equations  6  and  7  equate 
the  values  of  the  Bernoulli  quantity  at  terminals  1  and  2  to  the  value  at 
the  reservoir's  surface.   The  fluid  pressure  at  the  surface  is  assumed 
to  be  one  atmosphere  and  the  fluid  velocity  at  the  surface,  HS',  is 
assumed  to  be  so  small  that  it  has  no  effect  on  the  value  of  the  Bernoulli 
quantity  there.   Thus,  the  value  of  the  Bernoulli  quantity  at  the  surface 
is  assumed  to  be  HS. 

Pipe  Element 

This  element  can  be  used  to  interconnect  reservoirs  and  fluid 
sinks.   It  might  be  represented  graphically  as  shown  in  Figure  1.2c.   The 
element  model  includes  two  connection  points — terminals  1  and  2 — ,  the 
associated  variables  B-.  ,  FLOW  ,  B  ,  and  FLOW  ,  and  the  following  variables 
and  parameters: 
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A  the  cross-sectional  area  of  the  pipe,  a  parameter  of  the  element; 

V  the  velocity  of  the  fluid  through  the  pipe,  a  local  variable; 

H  the  height  of  terminal  1,  a  parameter; 

P,  the  fluid  pressure  at  terminal  1,  a  local  variable; 

H„  the  height  of  terminal  2,  a  parameter; 

P9  the  fluid  pressure  at  terminal  2,  a  local  variable. 

The  definition  of  the  pipe  element  is  completed  by  the  equations: 

1.  FLOW  +  FLOW  =  0 

2.  V  =  FLOW  /A 

3.  B   =  V2/(2*G)  +  H  +  P  /GAMMA 

4.  B   =  V2/(2*G)  +  H  +  P  /GAMMA 

5.  Bx  =  B2 

Equation  1  specifies  that  no  fluid  accumulates  in  the  pipe.   Equation  2 
defines  the  velocity  of  the  fluid  directed  from  terminal  1  toward  terminal  2 
through  the  pipe.   Equations  3  and  4  define  the  Bernoulli  quantity  at 
terminals  1  and  2,  respectively,  while  equation  5  equates  these  quantities. 

Since  the  head  loss  along  a  flow  line  is  not  modeled  in  this 
study,  the  pipe  element  simply  transmits  the  applied  flow  and  Bernoulli 
quantity.   Thus,  it  affects  connected  elements  as  though  it  were  only  a 
terminal.   If  the  fluid  pressures  and  velocities  within  the  pipes  are  not 
of  interest,  the  use  of  the  pipe  element  is  not  necessary.   Reservoirs  and 
sinks  can  be  connected  directly. 


Fluid  Sink  Element 

This  element  represents  the  flow  of  fluid  out  of  the  storm  sewer 
network  and  might  be  represented  graphically  as  shown  in  Figure  1.2d.   It 
has  one  terminal  which  can  be  connected  to  a  reservoir  either  directly  or 
through  a  network  of  pipes.   The  sink  has  two  parameters,  A  and  H,  which 
represent  the  cross-sectional  area  and  height  of  the  drain.   The  definition 


of  the  sink  element  is  completed  by  the  equati 


on 


B1  =  FLOW  2/(2*G*A2)  +  H 
which  defines  the  Bernoulli  quantity  at  the  drain,  where  the  pressure  is 
assumed  to  be  one  atmosphere. 

A  network  model  of  a  storm  sewer  system  can  be  constructed  by 
simply  interconnecting  various  instances  of  the  elements  described  above, 
assuming  automatic  handling  of  the  connective  equations. 
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Figure  1.2a.   Fluid  source  element  (rainfall) 


Figure  1.2b.   Reservoir  element 
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Figure  1.2c.   Pipe  element 


OU   » 


Figure  1.2d.   Fluid  sink  element 


Figure  1.2.   Graphical  representations  of  storm  sewer  network  elements 
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NOTES 


Continuous  and  discrete  methodologies  are  sometimes  coupled  in  so-called 
combined   simulations.   These  simulations  accommodate  both  discrete  and 
continuous  aspects  of  physical  systems  by  using  continuous  methods  to 
model  and  trace  continuous  responses  and  discrete  methods  to  model  and 
trace  discrete  responses.   A  good  example  of  a  combined  simulation  of 
a  tanker  fleet  can  be  found  in  A.  A.  B.  Pritsker's  GASP  IV  text  [3]. 

Analog  circuits  are  sometimes  interfaced  to  digital  procedures  in  hybrid 
simulations.   Typical  applications  of  hybrid  simulation  are  systems  in 
which  some  computations  require  the  very  high  accuracy  of  digital  methods 
while  others  require  the  extremely  rapid  response  of  analog  circuits. 
For  example,  hybrid  simulation  is  often  employed  in  ballistic  missile 
and  space  vehicle  applications  involving  guidance  systems  which  require 
very  high  accuracy  and  control  systems  which  require  very  high 
frequency  response. 

For  the  sake  of  consistency  all  values  of  FLOW,  are  assumed  to  be  directed 
into  the  element  in  question.   Thus,  the  rate  of  rainfall  is  -FLOW  ,  the 
rate  of  flow  directed  out  of  the  fluid  source  element. 
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2.   SURVEY  OF  DIGITAL  SIMULATION  LANGUAGES 

Whereas  modeling  for  analog  simulation  is  carried  out  by  wiring 
electrical  analogues  on  a  patchboard,  modeling  for  digital  simulation 
requires  the  use  of  a  programming  language,  which  we  will  refer  to 
subsequently  as  a  simulation  language.   Simulation  studies  can  be  and 
have  been  programmed  in  most  popular  computer  languages.   We  will  restrict 
our  attention  to  languages  intended  specifically  for  simulation,  which  are 
by  far  the  most  convenient  programming  languages  for  these  applications. 
We  will  begin  this  survey  of  simulation  languages  by  considering  the 
essential  processes  involved  in  a  simulation  from  the  highest  level  of 
abstraction.   We  will  classify  simulation  languages  into  several  broad 
categories  on  the  basis  of  how  certain  of  these  processes  are  carried  out 
by  the  languages  or  by  the  simulation  packages  with  which  they  are 
associated.   Then  we  will  proceed  to  survey  languages  in  greater  detail 
in  terms  of  their  features,  implementations,  and  the  design  goals  behind 
their  development. 

2.1.   Essential  Simulation  Processes 

A  simulation  study  typically  involves  the  iterative  execution 
of  the  processes  below: 

1.  Derivation  of  a  model  from  a  given  physical  system. 

2.  Formulation  of  a  problem- descriptive   model  of  the  system. 
Such  a  model  describes  the  problem  to  be  solved  but 
includes  no  explicit  statement  of  the  algorithmic  solution. 

3.  Formulation  of  a  procedure- adequate   model.  This  model 
explicitly  describes  the  algorithmic  solution  to  the 
extent  required  by  the  integration  program. 

4.  Integration  of  the  model  under  programmed  control. 

For  the  most  part,  process  1  is  the  province  of  the  simulation 
language  user.   No  simulation  packages  exist  which  can  automatically 
observe  the  operation  of  a  physical  system  and  postulate  a  mathematical 
model  based  on  these  observations.   On  the  other  hand,  the  term  'simulation 
package'  implies  that  process  4  can  be  carried  out  automatically.   Many 
simulation  studies  would  not  be  cost-productive  if  both  the  system  model 
and  the  integration  algorithm  had  to  be  programmed  as  'one-shots'. 
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Processes  2  and  3  are  facilitated  to  varying  degrees  by  various 
simulation  languages.   Since  we  are  primarily  concerned  with  simulation 
languages  in  this  survey,  we  will  concentrate  most  on  these  processes. 
Model  derivation  and  integration  techniques  will  be  dealt  with  sparingly 
and  only  where  they  touch  on  language  principles. 

2.2.   Basic  Language  Characteristics 

The  usual  characterizations  of  simulation  languages  concern 
the  classes  of  models  for  which  they  are  intended  and  the  structural    / 
requirements  of  the  model  definition.   The  classes  of  models  which  are 
accommodated  give  rise  to  the  classification  of  languages  as  either 
special  purpose  or  general  purpose.   Special  purpose  languages  are 
intended  only  for  a  limited  class  of  applications,  such  as  electrical 
circuit  analysis.   General  purpose  languages  can  accommodate  a  wide 
range  of  applications,  typically  all  systems  which  can  be  described  in 
terms  of  ordinary  differential  and  non-differential  equations,  with 
certain  restrictions  which  we  will  discuss  shortly. 

The  structural  requirements  of  the  model  definition  give  rise 
to  the  classifications  of  languages  as  either  block-oriented  or  equation- 
oriented,  and  as  either  procedural  or  parallel.   Block-oriented  languages 
are  those  in  which  the  equations  that  describe  the  model  are  formulated 
in  terms  of  networks  of  interconnected  functional  blocks.   This  is  a  very 
convenient  format  for  applications  in  network  analysis  because  the  user 
need  not  formulate  a  mathematical  model.   In  equation-oriented  languages, 
on  the  other  hand,  the  model  is  formulated  as  a  set  of  equations  which  is 
derived  more  or  less  directly  from  the  problem-descriptive  mathematical 
model.   This  permits  equation-oriented  languages  to  be  widely  applied. 

Procedural  languages  are  those  which  require  the  formulation  of 
equations  or  blocks  to  be  ordered  in  some  procedural  fashion  to  accommodate 
the  algorithmic  integration  of  the  model.   In  other  words,  they  require  a 
procedure-adequate  model  definition.   In  contrast,  parallel  languages 
permit  the  equations  or  blocks  to  be  formulated  as  an  unordered,  or 
parallel,  set.   The  language  processor  of  a  parallel  simulation  package 
automatically  synthesizes  a  procedure-adequate  model  from  the  parallel, 
problem-descriptive  model.   Thus,  parallel  packages  take  care  of  process  3 
as  well  as  process  A. 
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With  the  definitions  of  the  terms  'special  purpose',  'general 
purpose',  'block-oriented',  'equation-oriented',  'procedural',  and 
'parallel'  in  hand  we  will  proceed  by  discussing  where  the  popular 
simulation  languages  fall  in  terms  of  these  categorizations.   We  will 
also  introduce  a  number  of  languages  to  be  considered  as  examples  in 
observations  which  will  be  made  later. 

The  first  general  purpose  languages  which  were  developed  were 
block-oriented  due  to  a  desire  to  combine  the  computational  ability  of 
digital  computers  with  the  structural  organization  of  analog  computers 
then  in  use  for  simulation.   Models  were  constructed  from  interconnected 
functional  blocks  which  corresponded  for  the  most  part  to  available 
analog  elements  such  as  integrators,  multipliers,  etc.   Both  parallel 
and  procedural  versions  of  such  languages  were  developed  although  the 
parallel  versions  were  generally  accepted  as  easier  to  use  and  less 
error  prone.   Some  examples  of  general  purpose  block-oriented  languages 
are  ASTRAL,  DYSAC,  JANIS,  MIDAS,  and  PACTOLUS. 

Modern  general  purpose  languages  are  usually  equation-oriented 
due  to  a  desire  to  provide  for  generality  with  a  relatively  easy-to-use 
structural  format.   Block-oriented  languages  are  very  useful  for  constructing 
models  from  a  set  of  pre-defined  components,  particularly  in  special  purpose 
network  applications.   However,  for  general  models  the  most  frequently 
occurring  component  is  simply  an  equation.   Thus,  it  is  easier  to  construct 
general  models  directly  from  differential  and  algebraic  equations  than 
from  pre-defined  functional  blocks.   Despite  the  fact  that  parallel 
languages  are  generally  easier  to  use,  there  are  popular  general  purpose 
procedural  equation-oriented  languages  as  well  as  parallel  ones.   Some 
examples  of  general  purpose  parallel  equation-oriented  languages  are  MIMIC, 
DSL/90,  CSSL-III,  CSMP-III,  ASSL,  DARE-P,  and  ACSL.   The  most  important 
general  purpose  procedural  equation-oriented  language  is  GASP  IV. 

Special  purpose  languages  have  arisen  due  to  a  desire  to  provide 
extremely  easy  to  use  languages  for  certain  limited  applications.   They 
are  usually  block-oriented  and  parallel.   Their  block-orientation  arises 
from  the  desire  to  make  them  easy  to  use  rather  than  general.   Most  of  the 
block  types  required  for  modeling  are  pre-defined  within  the  language, 
freeing  the  user  of  having  to  formulate  differential  equations  defining 
their  behavior.   A  block  may  model  a  construct  which  involves  many 
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equations,  such  as  transistor,  or  a  single  transfer  function.   Modeling 
is  frequently  facilitated  by  the  automatic  association  of  certain  network 
equations,  such  as  Kirchoff's  laws  in  electrical  circuit  analysis,  with 
block  connections. 

The  typical  parallel  structure  of  special  purpose  languages 
also  arises  from  the  desire  to  make  them  easy  to  use.   Freeing  the  user 
of  having  to  model  at  an  equation  level  in  these  applications  seems  to 
imply  that  he  should  also  be  freed  of  having  to  order  the  implied 
equations  in  a  procedural  fashion. 

The  characteristics  mentioned  above  allow  special  purpose 
languages  to  achieve  great  modeling  power  within  their  scopes  of  applica- 
tions.  While  the  package  takes  care  of  processes  3  and  4,  the  use  of 
pre-defined  blocks  and  connection-implied  equations  allows  operations 
1  and  2  to  be  automatically  processed  to  a  large  extent  as  well.   Typically 
the  user  needs  only  to  select  the  desired  blocks  and  specify  their 
configuration  in  order  to  construct  the  desired  model. 

In  this  survey  we  will  limit  our  specific  comments  concerning 
special  purpose  languages  to  languages  for  electrical  circuit  analysis. 
The  most  important  observations  made  in  this  connection  can  be  applied 
to  nearly  all  special  purpose  network  languages.   Examples  of  special 
purpose,  parallel,  block-oriented  languages  for  electrical  circuit 
analysis  include  ECAP,  ECAP-II,  AEDNET,  SCEPTRE,  and  SUPER* SCEPTRE. 

The  tree  structure  of  Figure  2.1  indicates  where  digital 
simulation  languages  generally  lie  in  terms  of  their  scopes  of  application 
and  model  structures.   The  languages  which  we  have  selected  as  examples 
have  been  placed  in  this  tree  to  emphasize  their  characteristics.   The 
MODEL  language  which  is  the  subject  of  the  subsequent  chapters  is  a 
parallel,  equation-oriented,  general  purpose  language  which  is  designed 
to  allow  it  to  be  used  in  a  convenient  block-oriented,  special  purpose 
fashion  for  network  applications. 
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In  addition  to  the  above  methods  of  classifying  simulation 
languages,  we  now  introduce  a  new  classification  based  on  the  type  of 
integration  algorithm  to  which  a  language  is  designed  to  interface. 
Although  this  may  seem  an  artificial  method  of  classifying  languages, 
we  intend  to  show  that  it  is  both  appropriate  and  important.   To  this 
end  we  introduce  the  notions  of  explicit  and  implicit  integration. 

Explicit  integration  methods  are  memory  functions.   The 

computation  of  the  state  vector,  x>  at  time  t  does  not  depend  on  the 

derivative  vector,  x,  at  time  t,  but  only  on  values  of  x  and  x  at 

previous  times.   The  vector  equation 

x(t)  =  M(x(t  -  At),  x(t  -  At),...) 

describes  an  explicit  integration  method.   Method  M  is  used  to  compute 

the  state  vector  at  each  time  step.   The  state  derivative  vector  is  then 

calculated  directly  from  the  formulation.   For  this  reason  the  state 

equations  must  be  explicitly  formulated.   This  means  that  each  equation 

must  have  a  single  state  derivative,  x.,  or  a  single  auxiliary  variable, 

y.,  as  its  left  hand  side,  and  each  x.  and  y.  must  appear  as  the  left 
i  11 

hand  side  of  exactly  one  equation.   This  format  allows  the  state  and 
auxilliary  equations  to  be  used  as  assignment  statements  which  directly 
compute  x(t)  and  y(t),  once  they  are  arranged  in  the  proper  sequence. 
In  explicit  block-oriented  languages,  the  explicit  formulation  is 
handled  by  the  simulation  package,  which  formulates  all  equations.   In 
explicit  equation-oriented  languages,  the  user  must  supply  a  set  of 
explicit  equations. 

State  derivatives  may  not  appear  on  the  right  hand  sides  of 
explicit  equations  unless  they  are  also  defined  as  auxiliary  variables. 
Thus,  an  explicit  state  formulation  can  be  represented  in  vector  form  as 

Z(t)  =  g(x(t),  Z(t),  t) 
x(t)  =  f(x(t),  y(t),  t) 
Although  the  first  of  these  equations  is  implicit  in  vector  form  (X(t) 
is  a  direct  function  of  y(t)),  explicit  methods  require  that  no  algebraic 
loops  be  present  in  the  formulations  of  the  individual  y..   In  the  absence 
of  any  such  loops,  the  equations  can  be  arranged  in  a  fashion  which  allows 
direct  sequential  computation  of  a  solution  to  the  simultaneous  equations. 
This  involves  sorting  the  equations  so  that  each  auxiliary  variable  is 
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assigned  a  value  before  it  is  used  on  the  right  hand  side  of  another 
equation.  For  example,  we  consider  the  equations  below  which  define 
part  of  the  pilot  ejection  study  (see  [13]). 

X  =  XDOT 

Y  =  YDOT 


XDOT  =  U*COS(a)  -  V 

A. 

YDOT  =  U*SIN(a) 
If  executed  in  the  above  order,  these  assignment  statements  would  not 
compute  a  simultaneous  solution  of  all  equations  because  the  auxilliary 
variables  XDOT  and  YDOT  are  assigned  values  after  they  are  used  on  the 
right  hand  sides  of  other  assignments.   It  is  necessary  to  sort  this 
sequence  into  one  such  as 

XDOT  =  V*COS(a)  -  V 
X  =  XDOT 

YDOT  =  V*SIN(o) 
Y  =  YDOT 


in  order  to  obtain  a  simultaneous  solution  using  explicit  methods. 

This  sorting  process  is  what  is  meant  by  the  formulation  of  a 
procedure-adequate  model.   If  sorting  (of  equation  or  block  statements) 
must  be  performed  by  the  user,  the  language  is  called  procedural.   If 
sorting  is  performed  by  the  package,  the  language  is  called  parallel.   In 
either  case,  if  sorting  can  be  accomplished  it  is  computationally 
equivalent  to  performing  appropriate  substitutions  of  functions  of  x(t) 
and  t  only  for  any  y.(t)  which  appear.   Thus,  sorting  obtains  an  equivalent 
state  formulation  which  can  be  represented  as 

x(t)  =  f(x(t),  t). 
The  sequence  of  direct  computation  to  be  performed  at  each  time  step  is  then 

x(t)  =  M(x(t  -  At),  x(t  -  At),...) 

x(t)  =  f(x(t),  t) 
which  is  clearly  explicit. 
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Implicit  integration  methods  perform  a  computation  of  x(t) 
which  depends  on  x(t)  as  well  as  on  past  values  of  x  and  X.   The 
vector  equation 

x(t)  =  M(x(t),  x(t  -  At),  x(t  -  At),...) 
describes  an  implicit  integration  method.   These  methods  are  called 
implicit  because  they  introduce  algebraic  loops  into  the  computations. 
Even  if  the  state  formulation  is  sorted,  or  equivalently  is  given  by 

x(t)  =  f(x(t),  t) 
the  system  of  equations  which  must  be  solved  at  each  time  step  is 
implicit.   This  system  is 

x(t)  =  M(x(t),  x(t  -  At),  x(t  -  At),...) 

x(t)  =  f(x(t),  t) 
where  x(t)  is  a  direct  function  of  x(t)  and  vice  versa.   Because  of 
these  algebraic  loops,  implicit  integration  methods  must  use  iteration 
rather  than  direct  computation  to  evaluate  x.  and  x   at  each  time  step. 

In  the  past,  general  purpose  simulation  packages  have  always 
used  explicit  integration  methods  because  the  better  numerical  stability 
of  implicit  methods  was  not  thought  to  justify  the  higher  computation  time 
required  for  iteration.   However,  implicit  integration  can  be  justified 
for  numerical  reasons  (see  [1]).   Therefore,  we  consider  it  important  to 
consider  the  effect  of  implicit  integration  methods  on  the  ease  with 
which  certain  desirable  language  features  can  be  realized.   As  a  starting 
point  we  can  observe  that  the  two  major  restrictions  present  in  explicit 
equation-oriented  modeling — the  explicit  state  formulation  and  the 
requirement  that  the  set  of  equations  be  sortable — would  not  be  present 
in  an  implicit  language.   Because  implicit  integration  does  not  rely  on 
sorting  and  direct  computation  of  the  state  derivatives,  parallelism  is 
achieved  without  sorting  and  the  set  of  state  equations  need  not  be 
sortable  or  explicitly  formulated.   The  state  formulation  for  implicit 
integration  was  presented  above  as 

x(t)  =  f(x(t),  t) 
solely  for  the  sake  of  consistency.    State  equations  for  implicit 
integration  can  be  written  in  any  form  and  are  more  accurately  represented 
by  the  general  vector  equation 

g(x(t),  x(t),  t)  =  [0] 

At  present  the  special  purpose  package  ECAP-II  is  the  only  widely 

2 
available  package  which  uses  implicit  integration  exclusively. 
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2.3.   Essential  Features  of  Simulation  Languages 

There  are  certain  features  which  are  required  of  any  digital 
simulation  language  which  is  to  be  useful  for  simulation  studies.   These 
features  are  summarized  below.   They  are  included  at  this  point  because 
they  transcend  the  boundaries  of  the  various  language  types  and  have 
been  present  in  varying  degrees  in  all  simulation  languages  which  have 
been  developed. 

Essential  Features  of  Simulation  Languages 

1.  a  facility  for  formulating  state  equations,  including 
some  logical  capabilities; 

2.  parameterization  of  the  model; 

3.  control  over  the  simulation — initialization,  termination, 
repeat  runs; 

4.  recording  and  output  of  data — printing,  plotting; 

5.  control  over  the  integration — error  criteria,  stepsizes; 

6.  accommodation  of  changes  in  the  above. 

It  is  worth  restating  that  most  characterization  of  languages 
is  done  in  terms  of  their  facilities  for  state  formulation  (e.g.  equation- 
oriented  vs.  block-oriented, parallel  vs.  procedural).   However,  the 
realizations  of  others  of  these  features  will  also  prove  useful  as 
illustrations  of  shortcomings,  high-water  marks,  and  new  techniques  in 
simulation  languages. 

In  the  following  we  will  trace  the  historical  development  of 
goals  and  features  for  general  purpose  simulation  languages  in  some 
detail.   Then  we  will  consider  a  representative  family  of  special 
purpose  languages  (for  electrical  circuit  analysis) .   Special  purpose 
languages  will  be  discussed  in  considerably  less  detail  since  they 
differ  dramatically  from  general  purpose  languages  only  in  the  level 
of  abstraction  at  which  modeling  is  performed  (and  in  the  classes  of 
models  which  they  support) . 

2  .A.   The  First  Simulation  Languages — Digital  Analog  Simulators 

The  first  simulation  packages  offered  general  purpose  block- 
oriented  languages.   These  packages  were  initially  developed  to  generate 
check  solutions  for  analog  simulations.   Later,  many  were  designed  and 
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used  profitably  for  problem  solving.   All  were  designed  very  much  in  the 
structural  fashion  of  analog  simulation--modeling  was  accomplished  in 
terms  of  a  more  or  less  fixed  set  of  interconnected  blocks,  including  an 
integrator  block  to  describe  differential  equations.   Analog  simulation 
was  well  developed  while  digital  computers  were  still  in  their  infancy. 
Thus  early  simulation  users  were  all  users  of  analog  simulation.   For  this 
reason  Brennan  and  Linebarger  observed  in  their  excellent  survey  [2]  that 
the  block-diagram  approach  to  simulation  corresponded  to  the  way  an 
engineer  visualized  a  system  (at  that  time) .   Engineers  familiar  with 
simulation  had  learned  to  visualize  systems  in  the  form  of  an  analog  set- 
up diagram.   Brennan  and  Linebarger  summarize  in  part  by  stating  that 
"...it  is  of  paramount  importance  to  capture  the  interest  [in  digital 
simulation]  of  analog  users  in  order  that  their  vast  experience  not  be 
lost  as  simulation  enters  a  new  era."  Thus, designers  of  digital 
simulation  packages  and  languages  initially  opted  to  copy  closely  the 
structural  design  of  analog  computers.   The  general  purpose  block- 
oriented  packages  which  emerged  from  this  effort  have  been  commonly 
labeled  Digital  Analog  Simulators  or  DAS. 

In  terms  of  providing  the  essential  features,  DAS  languages  were 
adequate  but  inconvenient.   They  so  closely  resembled  analog  simulation 
that  they  typically  reflected  the  limitations  of  analog  elements  in  their 
operator  repetoires — i.e.  the  choice  of  functional  blocks  was  limited, 
limits  were  placed  on  the  number  of  inputs  and  outputs  a  block  could  have. 
DAS  languages  also  frequently  required  block  interconnections  to  be 
specified  in  a  rigid  format.   Thus,  they  were  not  really  a  convenient 
means  for  general  purpose  modeling,  merely  a  familiar  means.   Furthermore 
logical  switching  of  system  structure  was  generally  available  only  through 
the  use  of  relay  elements  and  logical  control  over  the  simulation  was  rare. 
Typical  termination  logic  consisted  only  of  a  total  time  specification. 
Most  DAS  languages  did  accommodate  changes  in  a  reasonable  fashion, 
allowing  any  one  of  the  structure,  control,  and  parameter  sections  to  be 
altered  without  affecting  the  others. 

2.4.1.   ASTRAL 

Despite  their  shortcomings,  languages  of  the  DAS  family  introduced 
a  number  of  language  and  implementation  features  which  increased  the  power, 
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flexibility,  and  ease  of  use  of  digital  simulation.   One  of  the  most 
innovative  was  ASTRAL  [3],  developed  at  Convair  Astronautics  in  1958. 
ASTRAL  is  most  significant  as  the  first  parallel  language.   The  automatic 
sorting  logic  required  to  synthesize  a  procedure-adequate  model  from  a 
problem-descriptive  or  parallel  one  was  first  presented  by  Stein  and 
Rose  in  [4]  and  first  implemented  in  ASTRAL. 

ASTRAL  was  also  the  first  simulation  language  to  be  implemented 
via  a  compiler,  rather  than  an  interpreter.   When  digital  simulation  is 
used  to  generate  a  check  case  for  analog  simulation,  a  program  is 
usually  run  once  and  discarded.   In  this  case  an  interpretive  approach 
is  quite  efficient.   However,  when  problem  solving  is  the  goal,  and  long 
runs  or  many  runs  with  the  same  configuration  are  required,  a  compiler 
approach  is  clearly  desirable.   The  ASTRAL  compiler  achieved  further 
advantage  by  using  FORTRAN  as  its  target  language.   By  using  FORTRAN 
as  the  intermediate  language,  a  package  can  avoid  having  to  support 
features  to  the  machine  level  via  its  own  software.   Efficient  code  can 
be  produced  fairly  quickly  by  exploiting  the  considerable  efforts  expended 
by  FORTRAN  designers.   Since  many  simulation  operations  can  be  programmed 
quite  easily  in  a  small  subset  of  FORTRAN,  only  minimal  effort  is  required 
of  the  simulation  package  to  support  these  operations.   Thus,  ASTRAL 
introduced  an  excellent  concept  which  reduces  the  amount  of  simulation 
software  required  at  very  little  cost  to  the  user.   In  fact,  a  reliance 
on  FORTRAN  is  often  to  the  advantage  of  the  user.   For  example,  it  was  a 
simple  matter  for  ASTRAL  to  include  a  'special  element'  block,  defined 
by  an  ordinary  FORTRAN  assignment  statement  which  could  utilize  any 
standard  FORTRAN  library  function.   In  this  fashion,  ASTRAL  was  the  first 
simulation  language  to  offer  an  extendible  operator  set.   This  represented 
a  first  step  toward  increased  operator  flexibility  for  simulation  languages 

2.4.2.   DYSAC 

DYSAC  [5] ,  which  was  developed  at  the  University  of  Wisconsin  in 
1961,  introduced  an  algebraic  block  connection  language  which  was  the  most 
significant  step  toward  greater  ease  of  use  since  ASTRAL  introduced 
parallelism.   DYSAC  used  a  symbol  which  consisted  of  a  letter  followed  by 
two  digits  to  represent  the  output  of  each  block.   While  the  letters 
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identified  the  block  types  (e.g.  N,  M,  A,  P  for  integrator,  multiplier, 
adder,  and  potentiometer,  respectively),  the  digits  identified  the 
particular  block.   Thus,  N02  represented  the  output  of  integrator 
number  2.DYSAC  allowed  a  sum  of  products  of  block  outputs  to  be  specified 
as  the  input  to  an  integrator.   Thus,  the  single  connection  statement 

N02  =  P06N02  +  P05P07N01 
might  serve  to  define  the  desired  output  of  integrator  number  2.   In  the 
absence  of  this  algebraic  capability,  four  connection  statements  to  the 
effect 

M01  =  P06N02 

M02  =  P05P07N01 

A01  =  M01  +  M02 

N02  =  A01 
would  be  required,  introducing  three  unnecessary  auxilliary  variables, 
M01,  M02,  and  A01 . 

The  observation  of  Brennan  and  Linebarger  that  this  algebraic 
interconnection  feature  provides  'simplicity  and  clarity'  and  shows 
'great  concern  for  the  user'  is  very  significant  in  that  it  shows  an 
early  desire  for  the  type  of  algebraic  capability  provided  by  equation- 
oriented  languages.   Unfortunately,  like  the  parallelism  of  ASTRAL,  the 
algebraic  capability  of  DYSAC  was  not  imitated  by  most  DAS  languages. 

DYSAC  was  also  the  first  language  to  provide  extensive  problem- 
specification  error  and  computational  difficulty  diagnostics.   This 
feature  is  very  important  as  program  failures  without  diagnostics  are 
extremely  frustrating  and  have  been  much  too  frequent  in  digital  simulation. 

2.4.3.   JANIS 

Reliance  on  FORTRAN  for  simulation  support  was  carried  beyond  the 
level  of  ASTRAL  by  another  compiler- implemented  DAS  language,  JANIS  [6], 
which  was  reported  at  Bell  Labs  in  1963.   JANIS  accepted  a  simple  FORTRAN 
subset  as  its  input,  and  implemented  functional  blocks  as  FORTRAN  subroutines, 
State  formulation  was  specified  by  a  procedural  sequence  of  CALL's  to 
functional  block  subroutines.   Block  numbers  were  used  as  the  arguments  of 
these  CALL's  to  specify  the  inputs  for  each  block.   While  this  basic 
structure  was  no  more  complicated  than  most  other  procedural  DAS  languages, 
it  permitted  two  great  increases  in  power  for  the  user  conversant  with 
FORTRAN.   Operator  extension  could  be  achieved  by  defining  new  functional 
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blocks  as  FORTRAN  subroutines.   Furthermore,  powerful  logical  control 
over  the  system  state  was  available  by  interspersing  FORTRAN  conditional 
branching  statements  among  the  CALL's. 

2.4.4.  MIDAS 

Perhaps  the  most  significant  DAS  of  all  is  MIDAS  [7].   It  was 
developed  at  Wright  Patterson  Air  Force  Base  in  1963.   MIDAS  has  been 
widely  credited  with  popularizing  digital  simulation,  as  attested  by  its 
use  at  nearly  a  hundred  installations.   Brennan  and  Linebarger  believe 
this  total  to  exceed  the  combined  useage  of  all  previous  simulation 
packages.   The  widespread  use  of  MIDAS  was  made  possible  by  its  imple- 
mentation on  the  popular  IBM  7090.   However,  it  suggests  another  important 
feature,  portability,  which  we  will  have  more  to  say  about  later.   MIDAS 
was  the  first  parallel  language  since  ASTRAL  and  thus  was  also  significant 
in  that  its  widespread  use  helped  to  popularize  parallel  languages,  just 
as  tbe  parallelism  of  MIDAS  accounted  in  part  for  its  popularity.   MIDAS 
presented  a  significant  innovation  of  its  own,  an  element  for  solving 
implicit  equations.   An  implicit  equation  such  as 

x  =  f(x,  y) 
where  x  appears  on  both  sides  of  the  equation  (that  is,  as  both  output 
and  input  of  the  block  f)  usually  requires  an  iterative  method  of  solution. 
All  simulation  packages  before  MIDAS  used  explicit  integration,  and 
provided  no  mechanism  for  iterating  implicit  equations.   Although  MIDAS 
also  employed  explicit  integration,  the  implicit  element  provided  by 
MIDAS  served  to  break  such  algebraic  loops,  which  would  otherwise  result 
in  sort  failures,  by  iterating  the  implicit  equation  without  time  advance 
until  convergence  was  attained.   It  is  worth  noting  that  implicit 
integration  algorithms  require  no  special  processing  in  order  to  handle 
implicit  equations  since  they  handle  all  equations  implicitly. 

2.4.5.  PACTOLUS 

PACTOLUS  [8],  which  was  developed  by  Brennan  for  IBM  in  1964,  was 
significant  in  its  interactive  approach  to  digital  simulation.   This 
package  served  to  demonstrate  that,  with  an  appropriate  terminal,  digital 
simulation  allows  the  user  the  sort  of  familiarity — that  is,  interaction — 
with  his  model  that  had  previously  been  restricted  to  analog  simulation. 
PACTOLUS  was  developed  as  an  interpreter  for  the  IBM  1620,  a  small  scientific 
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computer.   By  use  of  the  typewriter,  sense  switches,  and  1627  plotter  it 
allowed  the  user  to  interrupt  a  simulation  and  alter  its  configuration, 
parameters,  initial  values,  or  control  section  while  observing  the  response 
of  the  system.   PACTOLUS  became  very  popular  among  the  previously  untapped 
audience  of  small  installations.   In  addition,  a  completely  compatible 
version  was  developed  for  the  IBM  7090.   Thus,  the  user  who  had  access  to 
both  computers  could  perform  the  initial  checkout  off-line  and  then  switch 
to  the  1627  for  fine  tuning  of  the  model. 

PACTOLUS  provided  a  somewhat  better  capability  for  implicit 
equations  than  MIDAS.   PACTOLUS  also  achieved  a  degree  of  operator  flexibility 
previously  attained  only  by  JANIS  by  including  nine  special  elements  whose 
functions  could  be  easily  specified  by  the  user. 

General  purpose  block-oriented  simulation  packages — or  DAS's — were 
applied  to  a  wide  range  of  systems.   With  the  first  such  packages  the  limited 
set  of  available  operators  and  the  rigid  format  requirements  of  the  languages 
proved  great  drawbacks.   Later  languages  allowed  more  flexible  operator  sets 
and  formats  but  still  exhibited  the  principal  shortcoming  of  all  DAS's — 
algebraic  and  differential  equations  had  to  be  broken  down  into  functional 
blocks;  a  tedious  and  error-prone  process. 

On  a  superficial  level  DAS  languages  seem  quite  similar  to  the 
characterization  we  have  presented  of  special  purpose  languages.   However,  the 
similarity  extends  only  to  the  specialized  block-oriented  structure  of  each. 
Whereas  special  purpose  languages  can  automatically  formulate  equations  for 
limited  applications  on  a  level  which  is  hidden  from  the  user,  DAS  languages, 
which  were  intended  for  general  application,  required  the  user  to  formulate 
all  equations  himself  through  the  tedious  medium  of  blocks  which  modeled 
electrical  analogues.   Thus,  it  is  not  surprising  that  DAS  languages  have  been 
succeeded  in  usage  by  general  purpose  equation-oriented  languages. 

2.5.   Early  Equation-Oriented  Languages 

The  environment  in  which  the  first  equation-oriented  languages  were 
developed  was  well  summarized  by  Clancy  and  Fineberg  [9]  in  1965.   The  trend 
which  they  observed  was  toward  extension  of  the  power  and  utility  of  simulation 
programs.   Parallelism  was  recognized  as  an  extremely  useful  language  feature. 
Clancy  and  Fineberg  state  that  parallelism  "may  be  an  all-inclusive,  rational 
statement  of  the  essential  nature  (of  simulation  languages)"  and  urge  that 
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"If  the  programmer  is  to  'think  parallel1,  he  must  be  freed  of  ordering  problem 
statements."   Three  other  features  introduced  by  DAS  languages,  the  compiler 
approach  to  implementation,  the  provision  of  extendible  operator  sets,  and 
reliance  on  FORTRAN  support,  had  also  gained  widespread  acceptance.   Meanwhile, 
the  variety  and  complexity  of  functions  available  through  the  built-in  operator 
sets  continued  to  increase. 

However,  the  greatest  increase  in  utility  achieved  by  simulation 
programs  developed  during  this  period  came  about  through  the  introduction 
of  equation-oriented  languages  with  advanced  functional  and  logical 
capabilities  and  through  the  removal  of  arbitrary  format  restrictions  and 
analog  holdovers.   The  need  for  complex  networks  to  represent  algebraic 
and  functional  expressions  had  proved  a  great  inconvenience  in  the  use  of 
DAS  languages.   So  too  had  restrictive  features  like  absolute  rather  than 
symbolic  labeling,  poor  logical  capabilities,  fixed  input  card  formats, 
required  commas  and  decimal  points,  and  the  lack  of  numerical  literals. 
Along  with  improved  functional  and  logical  features,  the  new  equation- 
oriented  languages  offered  the  use  of  literals  and  symbolic  names  without 
reference  to  arbitrary  block  numbers.   Great  progress  was  also  made 
toward  a  free  problem  statement  format.   In  the  remainder  of  this  section 
we  will  discuss  MIMIC  and  DSL/90,  the  two  most  significant  equation- 
oriented  languages  developed  during  this  period,  in  some  detail. 

MIMIC  and  DSL/90 

Both  MIMIC  [10]  and  DSL/90  [11]  are  general  purpose  parallel 
languages  implemented  via  compilers.   Both  were  developed  for  the  IBM  7090 
family  of  computers  and  both  were  released  in  1965.   MIMIC  is  the 
successor  of  MIDAS  and  was  developed  by  Petersen  and  Sansom  at  Wright 
Patterson  Air  Force  Base.   DSL/90  is  a  descendant  of  JANIS  and  was 
developed  by  Syn  and  Linebarger  at  the  IBM  Development  Labs.   Both  MIMIC 
and  DSL/90  are  explicit  languages.   Thus,  the  state  equations  must  be 
formulated  explicitly  and  must  constitute  a  sortable  set.   Within  these 
limitations,  MIMIC  and  DSL/90  allow  great  functional  power  in  the 
formulation  of  the  state  equations.   We  will  begin  this  discussion  of 
their  most  important  features  by  considering  the  functional  capabilities 
of  MIMIC  and  DSL/90  statements. 
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2.5.1.   Functional  Capabilities 

Both  MIMIC  and  DSL/90  allow  free  use  of  fully  symbolic  variable 

names,  numerical  literals,  and  the  common  infix  arithmetic  operators  +,  -, 

*,  and  /  within  any  equation.   Both  allow  expressions  involving  any  of  the 

built-in  operators  to  be  nested  to  any  level  of  parenthesis.   Together 

these  features  provide  a  great  improvement  over  DAS  languages  in  the 

functional  complexity  which  can  be  expressed  in  a  single  statement.   As 

we  have  seen,  a  single  DYSAC  connection  statement  could  be  used  to  express 

a  sum  of  products  as  the  input  to  an  integrator.   Another  DAS  language, 

DES  1  [12],  carried  algebraic  capabilities  to  the  ultimate  by  allowing 

nested  sums  of  products  and  quotients  to  be  expressed  in  a  single  block 

connection  statement,  but  failed  to  provide  infix  operators  for  the 

3 
common  arithmetic  operations.    MIMIC  and  DSL/90  fill  this  need  and 

provide  the  full  algebraic  capability  of  DES  1.   MIMIC  and  DSL/90  also 

provide  greater  functional  capability  in  a  single  statement  by  allowing 

nesting  of  all  built-in  operators,  not  just  the  common  arithmetic  operations, 

The  usefulness  of  nesting  built-in  operators  is  evident  in  the 
consideration  of  a  solution  to  a  system  such  as  Mathieu's  equation 
x  +  (a  -  2q  cos  wt)x  =  0    where  a,  q,  and  w  are  constants. 
This  equation  describes  a  number  of  engineering  and  mathematical  systems. 
To  formulate  this  problem  in  DES  1  would  require  three  blocks;  two 
integrators  and  a  cosine  function  generator.   Three  connection  statements 
would  be  needed.   More  connection  statements  would  be  needed  in  any  other 
DAS  language  because  multiplication  and  addition  blocks  would  be  required. 
However,  if  x  is  to  be  the  only  output  variable,  this  system  can  be 
expressed  in  a  single  statement  in  either  MIMIC  or  DSL/90.   These  state- 
ments would  be 

DSL/ 90:   X=INTGRL(XO,INTGRL(0.,-X*(A-2*Q*COS(W*TIME)))) 
MIMIC:    X=INT(INT(-X*(A-2*Q*C0S(W*TIME)),0.),X0) 
where  X(0)  =  XO  and  X(0)  =  0. 

The  nesting  of  the  integration,  cosine,  and  arithmetic  operators 
permits  a  problem  statement  which  closely  resembles  the  manner  in  which 
the  user  envisions  the  system — that  is,  as  a  single  differential  equation 
with  initial  values.   The  principle  advantage  of  operator  nesting  is 
that  it  eliminates  the  need  for  complex  networks  to  represent  expressions 
which  are  regarded  as  single  functional  elements.   This  also  means  that 
nesting  eliminates  the  need  to  explicitly  formulate  most  auxiliary  variables. 
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There  are  two  important  differences  in  the  functional  complexity 
which  can  be  expressed  by  single  MIMIC  and  DSL/90  statements.   The  first 
concerns  a  restriction  on  the  manner  in  which  the  INTGRL  operator  can  be 
imbedded  algebraically  in  DSL/90.   DSL/90  requires  that  INTGRL  be  the 
rightmost  term  at  every  level  of  its  usage.   This  artificial  restriction 
is  imposed  to  facilitate  the  recursive  extraction  of  implied  auxilliary 
variables  from  nested  occurrences  of  INTGRL.   MIMIC  allows  the  INT 
operator  to  be  embedded  freely  at  all  levels  of  nesting  and  is  more 
convenient  in  this  respect.   The  second  important  difference  concerns 
the  manner  in  which  user-defined  functions  can  be  used.   DSL/90  allows 
user-defined  function  operators  to  be  embedded  in  expressions  as  freely 
as  the  built-in  operators.   In  this  respect  DSL/90  is  more  convenient 
than  MIMIC,  which  allows  no  embedding  of  user-defined  functions. 

2.5.2.  Statement  Format 

With  respect  to  providing  a  flexible  format  for  problem 
statements,  DSL/90  is  clearly  superior  to  MIMIC.   In  brief,  MIMIC  can 
be  characterized  as  requiring  adherence  to  fixed  input  card  fields  and 
strict  ordering  of  data  cards.   DSL/90,  on  the  other  hand,  offers  a  free 
input  card  format  and  unordered,  symbolic  data  entry.   This  eliminates 
much  of  the  frustration  produced  by  coding  and  keypunch  slips  and  allows 
easier  changing  of  parameter  and  initial  values. 

2.5.3.  Built-in  Operators 

Both  DSL/90  and  MIMIC  offer  substantial  improvements  over  DAS 
languages  in  their  facilities  for  supporting  essential  mathematical, 
logical,  and  simulation  control  operations.   The  most  significant 
differences  between  DSL/90  and  MIMIC  with  respect  to  these  built-in 
operators  stem  from  DSL/90' s  heavy  reliance  on  FORTRAN  for  software 
support.   The  DSL/90  compiler  uses  FORTRAN  as  its  target  language  and 
accepts  a  subset  of  FORTRAN  mathematical  and  logical  operations  within 
its  input  language.   DSL/90  also  relies  on  a  user-written  FORTRAN 
program  to  control  the  simulation  study.   In  contrast,  the  MIMIC  compiler 
produces  near  machine-level  function  code  and  all  built-in  operations 
must  be  supported  to  this  level  by  MIMIC  software.   Thus,  MIMIC  logical 
and  simulation  control  operators  are  quite  different  in  form  from  the 
corresponding  FORTRAN  operators  used  in  DSL/90. 
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Mathematical  Operators 

As  we  have  seen  in  the  discussion  of  their  functional  capabilities, 
MIMIC  and  DSL/90  provide  significant  advances  over  DAS  languages  in  the  ease 
with  which  mathematical  operations  can  be  programmed.   Both  languages  provide 
the  most  frequently  used  simulation  operators,  such  as  integration, 
differentiation,  implicit  equation  solution,  time  delay,  and  zero-order  hold. 
Both  also  provide  the  most  frequently  used  function  generators,  such  as 
absolute  value,  square  root,  exponentiation,  logarithm  extraction,  and  the 
trigonometric  functions.   There  are  some  differences  in  the  more  sophisti- 
cated operators  provided  by  DSL/90  and  MIMIC,  but  most  operators  not  common 
to  both  can  be  implemented  relatively  easily  by  the  user.   The  implementation 
of  DSL/90  allows  it  to  offer  all  standard  FORTRAN  library  functions  as 
built-in  operators. 

Logical  Operators 

As  we  have  mentioned,  MIMIC  and  DSL/90  take  quite  different 
approaches  to  the  implementation  of  logical  operations,  but  both  permit 
much  easier  logical  switching  of  the  state  formulation  than  did  any  DAS 
languages  except  JANIS. 

DSL/90,  like  JANIS,  relies  on  FORTRAN  conditional  branching  for 
support  of  logical  state  switching.   Since  DSL/90  is  a  parallel  language, 
special  procedural  blocks  are  provided  for  branching  operations. 
Conditional  branches  are  intermixed  with  FORTRAN  and/or  DSL/90  statements 
within  procedural  blocks.   These  statements  are  not  resequenced  by  the 
sorting  process.   Instead,  the  procedural  blocks  are  treated  as  units 
in  the  sorting  process,  allowing  the  conditional  sequencing  inside  the 
blocks  to  be  handled  in  the  FORTRAN  step. 

MIMIC  supports  state  switching  by  means  of  logical  control 
variables,  or  LCV's.   An  LCV  may  be  attached  to  any  MIMIC  statement  to 
control  its  execution  at  each  time  step  of  the  simulation.   MIMIC  provides 
a  function  switch  operator  to  convert  arithmetic  relations  into  LCV's  and 
a  standard  set  of  Boolean  operators  to  logically  combine  LCV's.   This 
approach  is  more  elegant  than  DSL/90' s  in  that  no  proceduralism  is 
introduced  into  the  parallel  language. 
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Simulation  Control 

Simulation  control  encompasses  three  essential  operations; 
establishing  the  termination  conditions  for  each  run,  testing  of  system 
responses  between  runs,  and  generating  repeat  runs  with  altered 
parameter  and/or  initial  values. 

DSL/90  and  MIMIC  allow  both  time  and  dependent  variable 
termination  thresholds  to  be  established.   This  is  an  improvement  over 
most  DAS  languages,  which  allowed  termination  to  be  specified  by  elapsed 
time  only.   As  regards  response  testing  and  repeat  runs,  DSL/90  again 
relies  on  FORTRAN  while  MIMIC  employs  LCV's. 

DSL/90  supports  testing  of  system  responses  and  repeat  runs 
by  allowing  the  model  to  be  invoked  as  a  subroutine  from  a  FORTRAN 
main  program  which  is  submitted  with  the  model.   System  responses  may 
be  tested  and  parameter  values  may  be  assigned  by  any  FORTRAN  procedures. 
For  simple  studies  very  little  programming  sophistication  is  required,  e.g. 

DO  10  1=1,5 
PARAM=P(I) 
CALL  DSL 
10  CONTINUE 
On  the  other  hand,  sophisticated  studies  can  make  use  of  FORTRAN  procedures 
for  things  such  as  parameter  optimization.   DSL/90  was  the  first  language 
to  provide  this  type  of  simulation  control,  which  is  clearly  desirable. 

MIMIC  supports  response  testing  via  LCV's.   The  termination  of 
a  run  causes  a  particular  LCV  to  become  'true'.   This  LCV  can  be  used  to 
cause  the  execution  of  a  set  of  MIMIC  statements  which  perform  response 
testing  and  parameter  assignment.   Simulation  runs  are  automatically 
repeated  until  the  supply  of  data  cards  is  exhausted,  so  every  run  must 
read  at  least  one  data  card. 

Input/Output 

DSL/90  allows  parameter  and  initial  values  to  be  assigned 
symbolically,  e.g. 

PARAM  Pl=5. ,P2=7.3E+4 
ICON  X=0.0 
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These  data  cards  may  be  placed  at  any  point  in  the  input  deck  and,  with 
the  exception  of  the  label  in  columns  one  through  five,  may  be  punched 
in  free  format. 

MIMIC  data  cards  must  be  grouped  after  the  END  statement  and 
parameter  values  must  be  specified  in  the  order  in  which  the  parameters 
are  defined  in  the  body  of  the  program.   Data  cards  are  divided  into 
fixed  fields,  which  further  increases  the  likelihood  of  errors.   Trivial 
errors  are  also  invited  by  the  restriction  that  data  entered  in  the 
exponential  form  must  be  right-justified  in  the  data  field,  while  data 
entered  in  the  normal  form  need  not  be. 

DSL/90' s  facilities  for  data  entry  are  clearly  easier  to  use 
than  those  of  MIMIC  or  the  DAS  languages.   As  concerns  output  facilities, 
both  DSL/90  and  MIMIC  provide  the  same  basic  set  as  did  most  DAS 
languages:  printing,  plotting,  and  the  selection  of  titles  and  recording 
intervals.   MIMIC  provides  a  wider  variety  of  plot  options,  including 
the  ability  to  form  cross-plots. 

Integration  Control 

DSL/90  provides  extensive  features  for  controlling  the  integration 
process.   These  include  selection  of  the  algorithm  to  be  used  (choice  of 
four,  or  a  user-supplied  algorithm),  selection  of  the  minimum  and  maximum 
step  sizes  to  be  used,  and  specification  of  error  tolerances  for  individual 
state  variables.   These  are  useful  features  for  sophisticated  users,  but 
of  dubious  value  for  novices.   All  were  present  in  some  DAS  languages. 
MIMIC  allows  only  the  specification  of  minimum  and  maximum  step  sizes. 

2.5.4.   Facilities  for  Extending  the  Operator  Set 

User-Defined  FORTRAN  Subroutines 

As  we  have  seen,  some  DAS  languages  like  JANIS  allowed  user- 
defined  FORTRAN  subroutines  to  be  included  in  a  simulation  program.   Both 
DSL/90  and  MIMIC  carry  this  feature  farther  than  their  DAS  predecessors, 
though  MIMIC  exceeds  JANIS  in  this  respect  only  in  allowing  expressions 
as  arguments. 

MIMIC  requires  adherence  to  strict  format  rules  in  the  definition 
and  use  of  FORTRAN  subroutines.   At  most  five  of  these  may  be  used  in  any 
MIMIC  program  and  they  must  be  called  by  pre-defined  names.   Each 
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definition  must  include  exactly  seven  arguments  and  the  single  output 
value  must  be  defined  as  the  seventh  argument.   User-defined  FORTRAN 
subroutines  are  implemented  as  if  they  were  function  subroutines  (i.e. 
subroutine  SRI  is  invoked  in  the  form  Y=SR1 (arg. , . . . ,arg  )  )  but  they 
may  not  be  nested  or  embedded  algebraically  in  equations.   Each 
reference  must  be  the  only  term  at  the  highest  level  of  the  right  hand 
side,  just  as  if  it  were  a  DAS  functional  block. 

In  DSL/90,  the  user  may  define  FORTRAN  function  subroutines. 
No  restrictions  are  placed  on  their  definition  and  use,  other  than  those 
imposed  by  FORTRAN.   Any  number  of  function  subroutines  with  fully 
symbolic  names  may  be  defined.   References  may  be  nested  and  embedded 
algebraically  in  any  fashion  permitted  by  FORTRAN.   Thus,  DSL/90 
represents  the  ultimate  in  usage  of  FORTRAN  function  subroutines,  being 
fully  as  flexible  as  FORTRAN  itself.   Of  course,  this  represents  no 
great  expense  of  effort  within  DSL/90  since  FORTRAN  is  the  target  language, 

MIMIC  Subroutines  and  DSL/90  Macros 

MIMIC  also  allows  extension  of  its  operator  set  by  the  use  of 
subroutines  written  in  the  MIMIC  language.   MIMIC  subroutines  offer  few 
advantages  over  FORTRAN  subroutines,  about  the  only  one  being  that  no 
knowledge  of  FORTRAN  is  required.   Since  MIMIC  does  not  allow  use  of  the 
integration  operator  in  subroutines,  they  serve  as  function  generators 
rather  than  as  a  means  of  defining  state  variables.   Apparently,  because 
MIMIC  subroutines  are  only  intended  as  function  generators  the  statements 
within  a  MIMIC  subroutine  are  not  sorted  with  respect  to  each  other.   One 
could  argue  that  a  procedural  language  can  be  very  useful  for  describing 
the  generation  of  a  complicated  function.   However,  proceduralism  in  MIMIC 
subroutines  is  unnatural  because  MIMIC  statements  are  otherwise  processed 
in  seemingly  parallel  fashion.   Proceduralism  for  function  generation 
seems  better  provided  by  an  associated  high  level  procedural  language, 
like  FORTRAN.   Like  the  FORTRAN  subroutines  permitted  within  MIMIC, 
MIMIC  subroutines  may  take  expressions  as  arguments  but  may  not  be 
nested  or  embedded  in  equations. 

DSL/90  allows  greater  extension  of  its  operator  set  by  its 
introduction  of  the  use  of  macros  in  simulation  languages.   DSL/90  macros 


38 


may  consist  of  a  mixture  of  DSL/90  and  FORTRAN  statements.   Like  MIMIC 
subroutines  they  are  repeatable  procedural  blocks  with  parameter  variations. 
The  important  difference  between  the  two  stems  from  the  in-line  generation 
of  macro  statements  which  takes  place  at  each  macro  invocation  in  the 
program.   After  this  preprocessing,  the  statements  generated  by  macros 
can  be  handled  like  any  other  statements.   Thus  it  represents  no  difficulty 
to  support  the  integration  operator  within  macros.   In  contrast  it  would 
be  difficult  to  support  the  integration  operator  within  subroutines 
because  normal  subroutine  linkage  does  not  suffice  to  establish  which 
arguments  are  defined  as  state  variables  within  the  body  of  the  subroutine. 
At  the  very  least,  the  compiler  must  inform  the  integration  program  which 
state  derivatives  are  to  be  integrated  and  thus  the  compiler  must 
determine  all  state  variables.   Since  DSL/90  macros  support  the  integration 
operator,  they  can  be  used  to  define  frequently  occurring  subsystem  states 
in  a  hierarchical  model  as  well  as  to  generate  functions.   This  facility 
makes  them  much  more  powerful  than  MIMIC  subroutines. 

Unfortunately,  like  MIMIC  subroutines,  DSL/90  macros  are 
sequenced  as  blocks  and  are  not  sorted  internally.   This  denies  the  user 
the  advantage  of  parallelism  in  defining  subsystem  states  and  also  fails 
to  take  advantage  of  an  important  difference  in  the  capabilities  of 
macros  and  subroutines  in  parallel  languages.   Subroutines  must,  of 
course,  be  sequenced  as  blocks.   However,  since  macros  are  expanded 
during  pre-processing,  it  is  possible  for  each  statement  generated  by  a 
macro  to  be  sequenced  into  the  sorted  program  separately.   This  facility 
would  be  more  in  keeping  with  the  nature  of  a  parallel  language  and  in 
some  cases  would  serve  to  break  what  would  otherwise  be  algebraic  loops. 

For  example,  in  modeling  an  electrically  controlled,  pressurized 
process,  one  might  define  macros  to  represent  the  elements  of  Figure  2.2. 
E   is  a  voltage  which  represents  a  pressure  measured  in  the  process  S. 
The  pressure  transducer  converts  this  signal  into  the  pressure  P  .   The 
atmospheric  adapter  adjusts  P   for  the  ambient  air  pressure  P  .   The 
adjusted  pressure  is  P„ .   The  transducer  converts  P~  into  a  voltage 
signal,  E   which  is  used  to  control  process  S.   If  the  two  macros  are 
to  be  sequenced  as  blocks,  they  represent  an  algebraic  loop.   The  input 
of  the  atmospheric  adapter,  P  ,  is  determined  by  the  transducer,  while 
one  of  the  inputs  of  the  transducer,  V        is  determined  by  the  adapter. 
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However,  if  the  statements  generated  by  the  transducer  can  be  sequenced 
separately,  the  loop  can  be  broken  by  the  sequence 

pi  ■  £(Ei> 

P2  "  Pl  +  P0 
E2  =  f"1  (P2) 


PROCESS  S 
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PRESSUPvE   TRANSDUCER 

'(E] 
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V 


(P2) 


-O 


ATMOSPHERIC 
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P   =  P   -  P 
2    1    0 


Figure  2.2.   Macros  for  an  electrically  controlled, 
pressurized  process,  S. 

Table  Functions 

Both  DSL/90  and  MIMIC  provide  another  important  means  of 
extending  their  operator  sets — the  ability  to  enter  tabular  data  functions, 
This  feature,  which  allows  experimentally  observed  functions  of  one  or 
two  variables  to  be  included  in  system  model  formulations,  was  not 
commonly  available  in  DAS  languages . 


2.5.5.   Diagnostics 

Since  the  innovations  of  DYSAC,  users  have  become  increasingly 
concerned  with  the  desire  for  extensive  and  easily  understandable  diagnostics 
Little  information  concerning  DSL/90  diagnostics  is  available  to  this 
author.  Tt  is  clear  that  MIMIC  does  not  offer  extensive  diagnostics  at  the 


40 


problem  description  level.   MIMIC  does  a  fine  job  of  reporting  format 
errors  and  references  to  undefined  variables  and  operators.   However, 
diagnostics  concerning  algebraic  loops  and  syntax  errors  in  arithmetic 
expressions  are  not  input  statement  specific.   They  are  reported  at 
the  near  machine  code  level  rather  than  at  the  problem  description 
level.   This  makes  problem  debugging  unnecessarily  difficult,  and  nearly 
impossible  for  the  user  who  is  unfamiliar  with  assembly  languages. 

2.6.   Modern  General  Purpose  Languages 
2.6.1.   General  Trends 

The  development  of  the  third  generation  of  general  purpose 
simulation  languages  was  channeled  largely  by  the  efforts  of  the  SCi 
Committee  on  Simulation  Software,  which  was  organized  in  1965.   During 
the  preceding  years,  a  large  number  of  digital  continuous  system  simulation 
packages  had  been  reported.   The  SCi  Committee  grew  out  of  a  general 
feeling  that  some  sort  of  control  and  direction  was  needed  in  the  area  of 
digital  continuous  simulation  in  order  to  insure  orderly  development  of 
the  field.   The  Committee's  efforts  to  provide  this  direction  took  the 
form  of  a  set  of  specifications  for  a  proposed  continuous  system  simulation 
language  (generically  called  a  CSSL) ,  which  was  published  in  1967  [13].   These 
specifications  were  presented  in  the  form  of  a  communication  language,  with 
little  concern  paid  to  strict  detail  or  to  problems  of  implementation.   In 
this  form  they  inspired  a  family  of  languages  and  paved  the  way  for  most  of 
the  significant  developments  which  have  followed. 

In  the  next  few  pages  we  will  turn  to  a  discussion  of  the  primary 
goals  for  language  development  which  were  presented  in  [13].   This  discussion, 
along  with  some  elaboration  on  the  part  of  this  author,  will  provide  the 
framework  for  a  discussion  of  the  most  significant  languages  and  features 
developed  since  1965. 

SCi  Committee  on  Simulation  Software — Goals  for  Language  Development 

In  their  survey  [9],  Clancy  and  Fineberg  had  proposed  a  user- 
oriented  organization  for  simulation  languages,  with  basic  subsets  for 
less  sophisticated  users  and  more  complex  features  for  experts.   In  this 
way  the  language  would  not  be  tied  to  any  particular  programmer  level. 
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This  goal  was  also  emphasized  by  the  SCi  Committee,  which  considered  the 
applicable  programmer  levels  of  an  ideal  language  to  include  the  engineer 
or  scientist  unfamiliar  with  digital  techniques;  the  simulation  analyst, 
and  the  skilled  digital  applications  programmer.   To  provide  such  a 
user-oriented  organization  the  SCi  Committee  first  desired  "to  provide 
an  extremely  simple  and  obvious  programming  tool  for  the  novice  user 
with  a  straightforward  task."  This  implies: 

1.  a  minimal  set  of  operators  capable  of  handling,  in  a 
simple  manner,  most  problems  involving  differential 
equations ; 

2.  retention  of  proven  features  such  as  equation-oriented 
languages  and  parallelism; 

3.  a  complete  set  of  problem-oriented  diagnostics. 
Second,  an  attempt  was  made  to  provide  great  power  and 

flexibility  for  the  sophisticated  programmer  with  a  major  programming 
task.   This  led  to  the  requirements: 

1.  a  CSSL  should  provide  an  open-ended  operator  set  with  simple 
procedures  for  generating  operators; 

2.  a  CSSL  should  act  as  an  adjunct  to  an  established  procedural 
language,  e.g.  FORTRAN,  Algol,  PL/I; 

3.  a  CSSL  should  provide  a  programmable  rather  than  a  rigid 
structure  for  a  simulation  study. 

Open-ended  Operator  Set — Macros 

Most  of  the  attention  concerning  an  open-ended  operator  set 
was  focused  on  the  provision  of  macros.   The  SCi  Committee  observed  that 
"The  single  most  important  user  feature  is  the  concept  of  a  macro.   The 
user  may  define  macros  for  individual  problems  to  represent  commonly 
used  sets  of  descriptive  information.   These  macros  are  referenced  in 
his  program  exactly  as  though  they  were  operators  of  the  language.   In 
addition,  the  user  has  the  capability  of  creating  his  own  macro  library 
which  will  appear  to  the  system  as  an  extension  of  and/or  replacement 
of  the  system  library.   Thus,  each  user  may  completely  alter  the  semantics 
|of  the  language  while  preserving  the  syntax  and  the  structure  of  the 
operational  environment." 
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The  macro  concept  touches  on  what  Clancy  and  Fineberg  considered 
to  be  the  principle  drawback  of  equation-oriented  languages.   They  felt 
that  there  is  a  loss  of  familiarity  in  some  problems  when  common  block 
operators  are  not  emphasized.   They  further  observed  that  it  may  be 
inconvenient  to  express  certain  operators  in  equation  form,  including 
control  system  transfer  functions  and  non-linearities  such  as  hysteresis, 
dead  space,  and  limiters.   These  operators  are  much  more  familiar  as 
functional  blocks.   Clancy  and  Fineberg  suggested  that  the  language 
format  be  flexible  enough  to  match  the  natural  forms  of  diverse  problems. 
Equations  should  be  available  as  a  means  of  directly  modeling  differential 
equations  and  blocks  should  be  available  for  operators  common  to  popular 
applications.   Clearly,  macros  provide  a  convenient  means  of  defining 
common  operators  in  terms  of  equations  so  that  they  may  then  be  invoked 
in  a  form  similar  to  blocks.   The  SCi  Committee  considered  this  optional 
block  notation,  available  in  DSL/90,  to  be  a  proven  feature  which  should 
be  retained. 

Furthermore,  nested  macros  are  particularly  useful  for  modeling 
complex,  hierarchical  systems.   The  case  for  hierarchical  modeling 
techniques  is  well  presented  by  Clymer  in  [14] .   Since  many  physical 
systems  are  nearly,  if  not  perfectly,  hierarchical,  it  is  very  important 
for  a  simulation  language  to  provide  means  such  as  nested  macros  for 
structuring  models  in  a  hierarchical  fashion. 

Adjunct  to  an  Established  Procedural  Language 

We  have  previously  noted  the  usefulness  of  an  associated 
procedural  language  (nominally  FORTRAN)  for  exercising  logical  control 
over  the  system  state,  extending  the  function  list  via  user-defined 
subroutines,  and  for  programmed  control  over  the  repetitive  execution 
of  the  model.   For  simple  problems  little  or  no  use  of  the  associated 
procedural  language  is  required — to  the  advantage  of  the  user  with  no 
programming  experience.   On  the  other  hand,  the  associated  procedural 
language  provides  a  very  flexible  and  powerful  programming  tool  for 
sophisticated  programmers  and  problems.   The  associated  procedural 
language  can  be  employed  to  further  advantage  if  it  is  also  the  target 
language  of  the  simulation  language  compiler.   In  this  case  the  simulation 
package  can  make  extensive  use  of  existing  software  support.   It  is  this 
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dependency  on  the  associated  procedural  language  for  programming  flexibility 
and  for  software  support  that  was  advocated  by  the  SCi  Committee  in  stating 
that  the  simulation  language  should  act  as  an  adjunct  to  an  established 
procedural  language.   Such  a  structure  has  the  further  advantage  of  allowing 
the  experienced  programmer  to  alter  the  intermediate  model,  either  to 
avoid  recompiling  the  simulation  language  model  or  to  recover  from  errors 
in  the  simulation  compiler.   Should  the  simulation  package  itself  be 
programmed  in  the  associated  procedural  language,  a  high  degree  of  package 
portability  can  also  be  achieved.   The  importance  of  portability  was 
recognized  by  the  SCi  Committee,  which  considered  one  of  the  essentials 
of  an  ideal  language  to  be  that  it  be  usable  on  all  scientific  computers. 

Programmable  Structure 

The  type  of  facility  which  is  meant  by  a  programmable  structure 
for  a  simulation  study  is  the  ability  to  embed  the  simulation  model  within 
a  procedural  program  which  controls  its  repetitive  operation.   This 
program  would  typically  serve  to  test  system  responses  from  previous 
executions,  alter  model  and  control  parameters,  and  rerun  the  model 
until  the  study,  or  some  part  thereof,  is  completed  as  a  single  batch 
mode  job.   An  example  of  a  simulation  study  for  which  a  programmable 
structure  is  very  useful  is  the  calculation  of  the  envelope  of  safe 
pilot  ejection,  which  has  become  a  benchmark  problem  in  the  area  of 
digital  simulation.   The  purpose  of  this  study  is  to  determine  the 
trajectory  of  a  pilot  ejected  from  a  fighter  aircraft  and  to  ascertain 
whether  he  will  strike  the  vertical  stabilizer  of  the  aircraft.   Different 
combinations  of  aircraft  speed  and  velocity  are  investigated  since  the 
drag  on  the  pilot,  which  in  part  causes  his  horizontal  motion  relative  to 
the  aircraft,  is  a  function  of  both  air  density  and  velocity.   Thus,  a 
number  of  simulation  runs  with  different  values  of  the  altitude  and 
velocity  parameters  are  required.   It  is  convenient  to  be  able  to  program 
this  sequence  of  runs  as  a  single  batch  mode  job  which  alters  parameter 
values  procedurally  between  runs  rather  than  reading  parameter  data  for 
each  run.   Thus,  a  programmable  structure  is  quite  useful.   Furthermore, 
it  is  useful  for  the  programmed  structure  to  be  conditionally  dependent 
on  previous  solutions.   For  example,  if  ejection  is  safe  at  altitude  h 
and  velocity  V,  it  will  certainly  be  safe  at  altitude  h  for  smaller 
velocities  v  <  V. 
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A  programmed  structure  is  conceptually  simplified  if  the  model 
can  be  invoked  as  a  subroutine.   In  many  cases  it  is  also  useful  for  the 
controlling  program  to  be  able  to  interface  with  large,  user-supplied 
programs  for  such  things  as  parameter  identification  and  optimization. 
Since  only  relatively  slow  algorithms  exist  for  some  classes  of  simulation 
studies,  such  as  parameter  identification  and  optimization,  one  can  also 
see  the  usefulness  of  interactive  control  over  a  simulation.   Perhaps  the 
best  argument  for  the  provision  of  a  programmable  or  interactive  structure, 
rather  than  a  rigid  structure,  is  the  observation  of  the  SCi  Committee 
that  "The  language  designer's  view  of  simulation  is  formalized  in  the 
structure  of  his  language  and  subsequent  applications  are  limited  to  this 
concept."  Thus,  flexible  facilities  for  structuring  simulation  studies 
should  be  provided,  lest  the  rigid  structure  which  seemed  appropriate  to 
the  language  designers  prove  to  be  a  liability  to  potential  users. 

In  the  remainder  of  this  section,  we  will  focus  on  what  we 
consider  to  be  the  most  significant  general  purpose  languages  developed 
since  1965.   These  are  the  SCi  Committee-sponsored  CSSL-III  [15],  IBM's 
CSMP-III  [16],  DARE-P  [17] — developed  at  the  University  of  Arizona,  the 
Raytheon  Company's  RSSL  [18]  dialect  of  CSSL-III,  E.  L.  Mitchell  and 
J.  S.  Gauthier's  ACSL  [19],  and  A.  A.  B.  Pritsker's  GASP  IV  [20]. 

Before  considering  these  languages  individually  we  will  present 
a  brief  discussion  of  their  many  common  features.   These  are  summarized 
in  the  following. 

Common  Features  of  CSSL-III,  CSMP-III,  DARE-P,  RSSL,  ACSL,  and  GASP-IV 

1.  all  are  general  purpose,  explicit,  equation-oriented 
languages  implemented  via  compilers.   All  except  GASP-IV 
are  parallel  languages; 

2.  all  act  as  adjuncts  to  FORTRAN.   In  all  cases,  FORTRAN  is 
both  the  associated  procedural  language  and  the  target 
language  of  the  simulation  compiler; 

3.  all  offer  extendible  operator  sets  via  user-defined 
FORTRAN  subroutines.  All  except  DARE-P  and  GASP-IV 
offer  the  use  of  macros; 

4.  all  offer  procedural  sections  and  the  use  of  nearly  any 
FORTRAN  statements  within  these  sections.  This  is  most 
useful  for  logical  switching  of  the  system  state; 
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5.  all  except  GASP-IV  offer  nearly  free  (explicit)  equation 
formats,  fully  symbolic  names  and  symbolic  data  input; 

6.  all  offer  great  functional  capabilities  by  allowing  all 
built-in  operators  and  user-defined  functions  to  be 
freely  nested  and  embedded  in  equations; 

7.  all  offer  a  flexible  complement  of  operators  for  data 
recording,  printing,  and  plotting; 

8.  all  offer  operators  for  solving  implicit  equations; 

9.  all  allow  the  user  to  enter  tabular  data  functions; 

10.  all  offer  flexible  control  of  simulation  studies  via 
programmable  structure  or  interactive  operation; 

11.  all  offer  a  choice  of  integration  methods,  step  sizes, 
and  error  tolerances. 

2.6.2.   CSSL-III 

CSSL-III  is  the  product  of  a  line  of  development  at  Control  Data 
Corporation  which  began  with  the  sponsorship  of  the  SCi  Committee  on 
Simulation  Software  in  1967.   Like  previous  versions  of  CSSL,  CSSL-III, 
which  was  released  in  1971,  adheres  closely  to  the  specifications  presented 
in  [13]. 

Structuring 

CSSL-III  provides  generous  structuring  capabilities.   Simple 
problem  statements  may  be  unstructured  by  default,  consisting  of  a  single 
DYNAMIC  block.   Sophisticated  studies  may  be  explicitly  structured  via 
INITIAL,  TERMINAL,  and  DYNAMIC  regions.   These  codes  are  executed, 
respectively,  before,  after,  and  at  each  communication  interval  of  the 
model  simulation. 

Simple  problems  are  structured  by  default  as  one  DYNAMIC  region. 
The  model  equations  are  specified  in  the  parallel  DERIVATIVE  subregion  of 
the  DYNAMIC  region.   The  remainder  of  the  DYNAMIC  region  specifies  the 
model  termination  condition,  the  integration  parameters  (method,  step 
size,  error  tolerance),  and  any  data  recording  calculations  which  need 
be  performed  only  at  communication  intervals.   The  explicit  equations 
of  the  DERIVATIVE  subregion  are,  of  course,  executed  during  each  time 
step  of  the  integration. 
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The  INITIAL  and  TERMINAL  regions  are  procedural  codes  which 
permit  nearly  any  FORTRAN  statements  and  may  invoke  any  user-supplied 
FORTRAN  subroutines.  They  can  perform  response  testing  and  parameter 
setting.  Studies  consisting  of  repeat  runs  can  be  specified  by  condi- 
tional branches  from  the  TERMINAL  region  to  points  within  the  INITIAL 
region. 

A  programmed  study  is  invoked  by  a  deck  of  CSSL  run-control 
cards  which  must  be  submitted  to  the  CSSL-III  compiler  along  with  the 
model  definition.   The  CSSL-III  executive  interprets  these  cards 
sequentially  at  run  time.   At  the  very  least,  a  START  command  must  be 
supplied  to  transfer  control  from  the  interpretive  monitor  to  the 
INITIAL  region.   Other  run-control  commands  serve  to  set  or  reinitialize 
parameters  and  select  output  variables  and  formats  for  the  study.   A 
SPARE  command  is  also  included  to  permit  linking  to  any  user-supplied 
FORTRAN  subroutine  with  that  name.   The  run-control  language  permits  no 
branching  or  looping,  but  does  permit  repetitive,  parameterized  operation 
of  the  programmed  study.   Each  time  execution  reaches  the  end  of  the 
TERMINAL  region,  control  returns  to  the  executive  for  subsequent  studies. 

CSSL-III  allows  further  program  structuring  by  means  of  segments, 
which  are  the  simulation  language  equivalent  of  the  closed  subroutine  of 
procedural  languages.   Segments  are  the  highest  level  blocks  within  a 
program.   Each  segment  contains  its  own  INITIAL,  TERMINAL,  and  DYNAMIC 
regions  and  performs  a  complete  simulation.   Segments  communicate  to  the 
rest  of  the  program  through  a  user-specified  set  of  variables  and  their 
execution  is  sequenced  by  FORTRAN  statements.   CSSL-III  segments  provide 
a  structure  applicable  to  simulations  using  multirate  integration  (through 
multiple  DERIVATIVE  subregions)  in  a  single  independent  variable.   This 
structure  also  allows  a  solution  to  one  set  of  differential  equations  to 
be  used,  for  example,  to  calculate  the  initial  conditions  for  the 
solution  of  another  set  of  equations  as  part  of  an  iterative  algorithm. 

Operational  Environment 

CSSL-III  is  designed  to  facilitate  on-line  operation  from  a 
remote  terminal  under  machines  of  the  CDC  6000  series.   The  advent  of  a 
package  with  advanced  language  and  computational  features  which  could  be 
run  as  a  batch  job  or  in  a  very  rapid  turnaround,  time-shared  environment 
was  a  significant  development.   The  terminal  user  can  perform  text-editing 
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and  recompilation  of  the  source  program  on-line  and  the  program  can  write 
data  on  the  remote  terminal  after  (though  not  during)  the  model  execution. 
Data  recorded  during  a  CSSL-III  run  is  routed  by  the  output  monitor  at  the 
point  between  reaching  the  model  termination  condition  and  the  execution 
of  the  TERMINAL  region. 

When  running  on-line,  the  user  may  interrupt  the  CSSL-III  study 
at  any  point,  but  would  typically  do  so  only  to  break  long  output  sequences 
or  to  abort  a  portion  of  the  study.   A  TELEX  operator  (peculiar  to  the 
KRONOS  operating  system  for  CDC  6000  series  machines)  can  be  used  to 
specify  an  address  in  the  TERMINAL  region  to  which  control  is  transferred 
at  an  interrupt.   If  the  TELEX  instruction  is  omitted,  control  is 
transferred  to  the  executive,  which  proceeds  to  interpret  the  next  run- 
control  card. 

CSSL-III' s  on-line  operation  and  interpretive  run-control  point 
toward  an  interactive  operation  similar  to  that  of  less  powerful  predecessors, 
like  PACTOLUS.   For  true  interaction  the  features  of  CSSL-III  need  only  be 
extended  to  allow  run-control  commands  to  be  issued  one  by  one  from  the 
remote  terminal  and  to  allow  monitoring  output  to  be  written  on  the  terminal 
during,  rather  than  after,  the  model  execution. 

Macro  Capabilities 

CSSL-III  provides  very  powerful  macro  capabilities.   The  CSSL-III 
language  includes  a  macro  interpretive  language  which  can  be  employed  in 
macro  definitions.   This  language  includes  a  powerful  set  of  commands  which 
are  interpreted  at  the  macro  level.   A  macro  loop,  for  example,  will 
generate  the  included  statements  as  many  times  as  the  loop  is  executed. 
The  CSSL-III  language  also  incorporates  a  symbolic  macro  library  from  which 
previously  defined  macros  can  be  selected  for  modeling.   User-defined 
macros  can  be  added  to  the  symbolic  library,  which  also  provides  a  number 
of  system  macros  for  such  operations  as  hysterisis,  limited  integration, 
and  first  order  pole.   After  macro  references  are  expanded  by  the  macro 
interpreter,  all  statements  generated  by  macros  are  sequenced  individually 
into  the  sorted  model. 
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Arrays 

CSSL-III  allows  the  definition  and  use  of  array  variables  and 
includes  an  array  integration  operator.   This  represents  an  advance  in 
functional  capability  for  systems  which  can  be  described  in  part  by  array 
operations.   However,  common  operations  such  as  array  multiplication  and 
addition  must  be  implemented  by  user-supplied  code.   References  to 
particular  array  elements  are  supported  in  one  dimension  only.   For  two 
or  three  dimensional  arrays  the  user  must  program  the  subscript 
calculations  himself. 

2.6.3.   CSMP-III 

The  IBM  CSMP-III  package,  released  in  1971,  is  very  similar  to 
CSSL-III.   Like  CSSL-III,  CSMP-III  is  the  product  of  a  line  of  development 
dating  back  to  the  SCi  Committee  on  Simulation  Software  publication  [13] , 
and  adheres  closely  to  these  specifications.   CSMP-III  is  somewhat  less 
sophisticated  than  CSSL-III.   Here  we  will  focus  attention  briefly  on 
those  features  of  CSSL-III  not  available  in  CSMP-III.   Otherwise,  the  two 
languages  are  all  but  identical  in  terms  of  structure,  power,  and  flexibility. 

CSMP-III  does  not  provide  a  macro  interpretive  language.   No 
commands  are  interpreted  on  the  macro  level.   Macro  expansion  consists 
simply  of  generating  the  statements  of  the  macro  definition  sequentially, 
with  parameter  substitutions. 

CSMP-III  does  not  allow  programs  to  be  divided  into  segments. 
Thus,  any  given  programmed  study  may  involve  the  solution  of  only  one  set 
of  differential  equations.   All  equations  must  be  integrated  by  the  same 
method  and  at  the  same  rate. 

Finally,  CSMP-III  apparently  includes  no  special  provisions  to 
facilitate  on-line  operation.   Its  predecessor,  CSMP-S/360  [21],  was 
operated  in  batch  mode  only.   However,  a  batch  compatible  interactive 
version  of  CSMP  was  reported  by  Fairley  [22]  in  1971. 

2.6.4  RSSL 

RSSL  is  an  advanced  dialect  of  CSSL-III  which  was  developed  by 
E.  L.  Mitchell  and  J.  S.  Gauthier  at  the  Raytheon  Company  in  1973.  RSSL 
is  designed  to  accept,  without  change,  any  program  written  in  CSSL-III. 
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It  includes  innovations  in  the  handling  of  macros,  the  run  control 
language,  syntax  analysis  and  the  allocation  of  interval  data  space. 

Macros 

The  RSSL  translator  uses  a  stack  to  handle  macro  expansions 
so  no  artificial  limit  is  imposed  on  the  degree  of  macro  nesting. 
Furthermore,  the  user  need  not  avoid  the  names  of  system  macros  and 
operators  in  naming  macros.   The  user  dictionary  is  searched  first  in 
the  symbol  look-up  procedure. 

Run-control  Language 

RSSL  adds  three  new  operators  to  the  run-control  language  of 
CSSL-III.   The  PROCED  command  allows  the  definition  of  run-control 
procedures.   These  are  lists  of  sequential  commands  which  may  then  be 
invoked  by  a  single  word.   The  DISPLY  command  can  be  used  to  print  the 
current  values  of  a  list  of  variables.   This  is  a  very  useful  feature 
in  a  time-shared  environment.   The  ACTION  command  can  be  used  to  schedule 
data  changes  at  particular  values  of  the  independent  variable.   This  is 
useful  mainly  for  diagnostic  purposes.   For  example,  both  RSSL  and 
CSSL-III  provide  an  NDBUG  command  for  snapshot  printouts.   The  command 
NDBUG=10  causes  all  problem  variables  to  be  printed  at  the  first  ten 
time  steps.   The  ACTION  command  allows  the  user  to  obtain  debug  listings 
at  points  surrounding  areas  of  suspected  difficulty  by  changing  the 
value  of  NDBUG.   The  following  example  illustrates  this  operation  and  the 
form  of  the  ACTION  command. 

ACTION  ' VAR '=4.75,' VAL ' =10 , ' LOC ' =NDBUG 
This  command  sets  the  value  of  NDBUG  ('LOC*)  to  lO('VAL')  at  time  4.75. 
This  is  a  somewhat  confusing  format,  but  a  nice  feature  for  debugging. 

RSSL  run-control  also  includes  provision  to  overcome  the  usual 
problem  of  high  data  volume  through  a  remote  terminal.   Output  commands 
can  route  monitoring  information  to  the  terminal  while  sending  high 
volume  output  to  a  local  line  printer. 

Syntax  Analysis 

The  RSSL  translator  performs  syntax  analysis  on  the  model  source 
code,  an  improvement  over  reliance  on  FORTRAN  syntax  analysis,  which  is  the 
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policy  of  CSSL-III  where  arithmetic  expressions  are  concerned.   FORTRAN 
syntax  error  messages  are  confusing  to  the  user,  since  variable  names  are 
changed  and  parallel  statements  are  rearranged  before  the  FORTRAN  step. 
RSSL  does  not  perform  a  full  syntax  analysis,  only  the  first  error  on  any 
given  card  is  located. 

Internal  Space  Allocation 

All  data  internal  to  the  RSSL  translator  is  stored  in  floating 
tables  which  can  be  expanded  and  compressed  as  necessary.   Thus,  no 
artificial  limits  exist  on  any  program  elements.   Previous  languages  all 
had  fixed  limits  on  the  total  numbers  of  such  things  as  parameters, 
integrators,  variables,  etc. 

2.6.5.   DARE-P 

DARE-P  (for  Portable)  was  released  in  1975  by  Project  DARE, 
under  the  direction  of  J.  J.  Lucas  and  J.  V.  Wait  at  the  University  of 
Arizona.   In  addition  to  its  great  portability,  DARE-P  is  significant 
for  its  centralized  run-control  and  its  flexible  features  for  filing 
and  displaying  solutions. 

Portability 

The  DARE-P  language  acts  as  an  adjunct  to  ANSI  standard  FORTRAN 
[23] .   The  DARE-P  package  is  programmed  almost  entirely  in  this  subset  of 
FORTRAN,  resulting  in  great  portability.   To  further  enhance  portability 
by  reducing  core  requirements,  the  package  is  modularized  into  overlays. 
The  amount  of  machine  dependent  code  is  kept  to  a  minimum  by  the  use  of  a 
machine-independent  filing  structure  for  solution  histories  and  for 
communications  between  the  overlays,  and  by  techniques  such  as  packing 
characters  two  per  word  rather  than  using  a  tighter  packing  which  assumes 
a  word  length  of  more  than  16  bits.   Machine  dependent  code  is  isolated 
in  separate  modules,  and  an  implementation  guide  is  available  to  aid  in 
bringing  DARE-P  up  at  new  installations. 

The  DARE-P  package  requires  only  the  most  usual  sort  of  hardware 
Aside  from  sufficient  memory  (roughly  17K  DEC  10  words  or  21K  CDC  6400 
words,  for  example)  DARE-P  requires  an  input  device  for  entry  of  a 
problem  specification  file,  a  mass  storage  device  for  filing  operations 
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and  overlay  swapping,  and  an  output  device  capable  of  printing  132 
characters  per  line.   DARE-P  can  produce  CalComp  compatible  plotter 
output  for  installations  having  a  CalComp  compatible  plotter. 

Run-control 

All  DARE-P  run-control  is  programmed  in  the  LOGIC  block,  which 
invokes  the  model  execution  as  a  subroutine.   The  default  form  of  the 
LOGIC  block  consists  of  a  CALL  RUN  statement  which  executes  the  model  once. 
The  user  may  program  the  structure  of  a  study  by  using  CALL  RUN  statements 
in  conjunction  with  nearly  any  ANSI  FORTRAN  statements.   Special  subroutines 
are  provided  for  reinitializing  the  system,  adding  new  output  variables, 
and  filing  solution  histories  during  runs,  and  parameter  values  may  be 
selectively  altered  by  assignment  statements.   The  LOGIC  block  can  invoke 
any  user-supplied  FORTRAN  subroutines.   These  features  give  convenient 
control  with  a  wide  degree  of  freedom.   For  example,  large  codes  for 
parameter  optimization  can  be  linked  to  DARE-P  without  changing  the 
standard  system. 

The  centralized  run-control  of  DARE-P  is  conceptually  simpler 
than  the  structure  of  CSSL-III  where  branching,  looping,  and  interfaces 
with  FORTRAN  routines  are  programmed  in  the  INITIAL  and  TERMINAL  regions, 
and  the  specification  of  output  variables  and  filing  operations  are 
handled  in  the  run-control  deck.   Furthermore,  the  notion  of  INITIAL  and 
TERMINAL  codes  with  the  model  execution  implicitly  sequenced  between  them 
unnecessarily  restricts  the  manner  in  which  a  study  must  be  conceptualized. 
The  user  may  feel  more  natural  with  a  structure  showing  CALL  RUN  explicitly 
between  the  initial  and  terminal  codes,  or  with  several  CALL  RUN  statements 
spaced  throughout  the  program.   However,  CSSL-III 's  run-control  is 
somewhat  more  powerful  than  that  of  DARE-P,  allowing  different  output 
operations  and  formats  to  be  specified  for  particular  invocations  of  the 
programmed  study. 

Solution  Recording  and  Display 

The  DARE-P  LOGIC  block  supports  a  flexible  complement  of  filing 
operators  for  recording  solution  histories  and  solutions  during  and  after 
model  runs.   By  default,  all  state  variables  are  output  variables  and 
their  solution  histories  are  saved  on  the  TIME  file.   New  output  variables 
may  be  added  via  the  OUTPUT  list   command.   The  automatic  recording  of  all 
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solution  histories  can  be  disabled  and  re-enabled  by  means  of  CALL  STROF 
and  CALL  STRON,  respectively.   This  can  reduce  the  overhead  substantially 
and  thus  is  very  useful  when  a  complete  solution  history  is  not  required. 
Time  histories  of  selected  output  variables  may  be  recorded  by  executing 
a  CALL  SAVE  list  before  the  model  execution.   Each  CALL  SAVE,  up  to  five, 
uses  a  different  system  file  to  avoid  overwriting.   Final  values  of  the 
output  variables  may  be  saved  after  a  run  by  a  CALL  STORE  command.   This 
permits  solution  files  from  intermediate  runs  to  be  saved  and  re-entered 
in  subsequent  runs  via  the  CALL  RESET  command.   The  system  STORE  file  may 
be  used  to  store  end  results  for  subsequent  output  to  magnetic  tape  or  cards, 

DARE-P  also  offers  a  flexible  complement  of  output  operators. 
Conventional  printing  and  plotting  of  variables  against  time  is  supplemented 
by  operators  which  cross-plot  up  to  seven  variables  against  another  and 
operators  which  overplot  one  variable  from  up  to  five  solution  histories. 
Operators  are  provided  to  produce  time-plots,  cross-plots,  and  over-plots 
on  the  line  printer  and  to  produce  magnetic  tape  files  for  CalComp 
compatible  time-plots,  cross-plots,  and  over-plots.   Over-plots  are  not 
provided  by  the  CSSL-III  and  RSSL  packages. 

Equations 

The  equations  of  a  DARE-P  model  are  specified  in  the  DERIVATIVE 
block.   The  DARE-P  language  allows  for  two  DERIVATIVE  blocks,  permitting 
segmenting  as  in  CSSL-III.   However,  it  is  unclear  to  this  author  if  the 
DARE-P  run-time  overlay  presently  supports  this  feature — the  first  DARE-P 
release  did  not. 

The  format  of  DARE-P  equations  is  somewhat  more  natural  than  the 
formats  of  other  languages.   The  differentiation  operator  is  represented 
by  a  period  following  a  variable  name.   Differential  equations  are 
specified  in  the  form  je.  =  expression   rather  than  in  the  familiar  analog 
form 

X=INT (expression) 
It  is  worth  noting  that  the  use  of  the  differentiation  operator  rather  than 
the  integration  operator,  together  with  the  ability  to  formulate  equations 
implicitly,  would  allow  first  order  differential  equations  to  be  presented 
in  their  most  common  form.   Therefore,  this  minor  difference  is  of  some 
importance. 
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DARE-P  does  not  include  any  macro  capabilities,  but  a  version 
with  a  macro  handler  is  anticipated  at  the  Swiss  Federal  Institute  of 
Technology  in  [24] . 

2.6.6.  ACSL 

ACSL  was  reported  in  1976  by  E.  E.  L.  Mitchell  and  J.  S.  Gauthier, 
the  developers  of  RSSL.   ACSL  incorporates  the  same  structure  as  RSSL  and 
CSSL-III.   An  ACSL  model  consists  of  INITIAL,  TERMINAL,  DYNAMIC,  and 
DERIVATIVE  regions  and  is  exercised  by  sequential  run-control  statements. 
The  important  innovation  of  ACSL  is  its  interactive  operation.   Like 
CSSL-III  and  RSSL,  ACSL  is  designed  to  be  run  on-line  from  a  remote 
terminal.   ACSL  achieves  true  interaction  in  that  run-control  commands 
can  be  issued  and  executed  on-line  and  data  can  be  displayed  during  the 
model  execution.   ACSL  may  also  be  run  in  batch  mode  when  appropriate. 

The  ACSL  run-control  language  offers  all  features  of  RSSL 
run-control  with  the  exception  of  the  ACTION  and  SPARE  commands.   The 
model  execution  is  invoked  by  a  START  command  which  transfers  control 
to  the  INITIAL  region.   The  completion  of  the  TERMINAL  region  or  an 
interrupt  from  the  user  transfers  control  back  to  the  run-control 
interpreter  for  the  next  command.   Monitoring  output  may  be  routed  to 
the  remote  terminal  during  model  execution.   The  monitoring  interval  may 
be  any  integral  multiple  of  the  communication  interval  for  solution 
histories  to  reduce  the  frequency  of  transmissions  to  the  remote  terminal. 
High  volume  data  can  be  routed  to  a  local  line  printer  or  plotter  if 
available. 

ACSL  incorporates  all  of  the  advanced  features  of  RSSL.   These 
include  its  macro  interpretive  language,  dynamic  allocation  of  all 
internal  table  space,  arrays,  and  array  integration  operator.   ACSL  also 
performs  full  syntax  analysis  at  the  source  level. 

Some  concern  is  indicated  in  [19]  for  making  the  ACSL  model 
definition  section  machine  independent.   Versions  of  ACSL  are  reported 
running  on  CDC  6000  series  and  UNIVAC  1108  machines. 

2.6.7.  GASP  IV 

GASP  IV,  reported  in  1973,  represents  a  different  line  of 
development  than  the  languages  discussed  previously.   It  is  a  procedural 
language  in  which  model  definitions  are  programmed  directly  in  FORTRAN. 
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This  package  is  unfit  for  the  novice  user  due  to  its  lack  of  parallelism 
and  symbolic  naming  capabilities.   However,  it  provides  the  advantage 
of  efficiency  for  the  sophisticated  simulation  programmer  who  considers 
the  overhead  associated  with  advanced  features  such  as  sorting  to  be  a 
hindrance.   In  addition  to  continuous  models,  GASP  IV  supports  discrete 
and  combined  models  and  provides  extensive  features  for  discrete  modeling. 

Concerning  continuous  simulation,  GASP  IV  is  considerably  less 
powerful  than  the  languages  discussed  previously.   It  provides  no  macros 
and  only  a  limited  set  of  built-in  operators  to  aid  the  user  in  describing 
complex  continuous  models.   It  does,  however,  provide  the  facility  for 
incorporating  user-written  FORTRAN  subroutines  in  a  GASP  IV  model. 

A  continuous  GASP  IV  model  is  usually  programmed  as  four  FORTRAN 
subroutines.   These  specify  the  initialization  procedures,  the  recording 
of  system  status,  the  output  (in  addition  to  the  standard  GASP  IV 
summary  report),  and  the  state  equations.   Run-control  is  programmed  in  a 
FORTRAN  main  program  which  invokes  the  model  execution  as  a  subroutine 
via  CALL  GASP.   Great  flexibility  is  thus  available  for  response  testing 
and  initialization,  but  the  user  must  take  care  of  such  things  as 
dimensioning  and  allocating  COMMON  storage  for  GASP  variables. 

GASP  IV  is  highly  portable,  being  programmed  almost  entirely 
in  ANSI  FORTRAN. 

2.6.8.   Tabular  Summary  of  Modern  General  Purpose  Features 

The  most  important  features  of  the  modern  general  purpose 
languages  which  we  have  discussed  are  summarized  in  Figure  2.3.   In  this 
author's  opinion,  ACSL  and  DARE-P  are  the  most  advanced  languages  to 
date.   ACSL  is  unsurpassed  in  modeling  features  and  can  be  operated 
interactively.   DARE-P  is  cited  for  its  centralized  run-control  in  the 
form  of  a  FORTRAN  calling  program  and  for  its  flexible  features  for 
recording,  filing,  and  displaying  solutions.   DARE-P  is  further  recommended 
for  its  great  portability  and  nominal  cost. 
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Figure  2.3.   Table  of  features  of  modern  general  purpose  packages 


The  GASP  IV  package  has  extensive  run-time  library  routines  for  discrete 
simulation,  but  the  routines  for  continuous  simulation  are  rather  limited 


A  version  of  DARE-P  with  macro  handling  capability  similar  to  those  of 
CSMP-III  is  available  from  the  Swiss  Institute  of  Technology,  Zurich, 
Switzerland . 
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2.7.   Special  Purpose  Languages — Electrical  Circuit  Analysis 

Many  specialized  packages  have  spun  off  from  the  central  development 
scheme  of  continuous  simulation.   Applications  of  these  include  electrical, 
structural,  and  chemical  applications,  to  name  a  few.   These  languages  are 
distinguished  from  modern  general  purpose  languages  in  that  most,  if  not  all, 
modeling  is  carried  out  by  selecting  and  connecting  predefined  element  types 
which  are  natural  to  the  intended  discipline.   These  languages  provide  great 
convenience  for  suitable  applications,  but  lack  high-level  facilities  for 
handling  elements  and  connections  outside  the  intended  discipline  and  for 
solving  user-supplied  equations.   Here  we  will  concentrate  on  languages  for 
electrical  network  analysis,  which  are  a  representative  family  of  special 
purpose  languages.   We  will  be  concerned  with  features  for  network-oriented 
model  formulation  rather  than  with  generally  applicable  features  such  as 
run-control  and  input/output.   Advanced  run-control  and  input/output  features 
can  be  incorporated  in  special  purpose  languages  as  well  as  general 
purpose  ones,  though  no  existing  special  purpose  packages  provide  the 
flexibility  of  DARE-P ,  for  example,  in  these  respects.   The  most  important 
specialized  features  to  be  presented — graphical  modeling,  topological 
macros,  and  the  provision  of  specialized  interdisciplinary  modeling 
capabilities — can  be  incorporated  profitably  in  special  purpose  languages 
for  virtually  any  network  applications  in  the  physical  sciences.   So  too 
can  interactive  operation,  which  we  have  discussed  in  the  survey  of  general 
purpose  languages. 

2.7.1.   ECAP 

ECAP  [25]  is  a  linear  circuit  analysis  package  released  by 
IBM  in  1965.   It  represents  the  most  basic  realization  of  a  special 
purpose  language.   All  modeling  is  performed  by  interconnecting  predefined 
elements  which  represent  the  common  linear  elements  of  electrical  circuits. 
All  equations  are  specified  by  the  elements  and  their  connections  so  the 
user  does  no  modeling  at  the  equation  level.   However,  there  is  no 
facility  for  defining  new  elements,  either  in  terms  of  basic  elements  or 
in  terms  of  equations. 

Even  in  a  relatively  unsophisticated  language  like  ECAP  great 
modeling  power  is  inherent.   In  order  to  model  an  RLC  circuit  in  a  general 
purpose  language  such  as  ACSL,  an  engineer  would  be  forced  to  derive  an 
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explicit  formulation  of  the  state  equations.   A  procedure  for  this 
derivation,  in  which  the  state  variables  are  a  subset  of  the  capacitor 
voltages  and  induction  currents,  is  described  in  [26]  among  others. 

This  is  a  tedious  and  time-consuming  process  for  many  engineers, 

4 
particularly  for  complex  circuits.    To  model  a  linear  RLC  circuit 

using  ECAP,  on  the  other  hand,  one  need  only  select  the  elements  and 

specify  their  parameter  values  and  interconnections. 

ECAP's  inability  to  handle  nonlinear  elements,  including  diodes 

and  transistors,  is  a  severe  handicap  for  circuit  analysis.   Furthermore, 

ECAP  converts  a  source  language  model  into  a  set  of  nodal  equilibrium 

equations  to  be  solved  at  each  time  step  of  the  integration.   This 

technique  requires  complete  recalculation  of  the  equations  whenever  a 

parameter  is  changed,  making  circuit  design  with  ECAP  extremely  expensive. 

2.7.2   AEDNET 

AEDNET  [28]  is  a  sophisticated  but  nonportable  package  for  linear 
and  nonlinear  circuit  analysis  reported  at  the  MIT  Electronic  Systems  Lab 
in  1966.   AEDNET  operates  interactively  on  a  time-shared  computer  and  a 
CRT  display  unit,  which  provides  on-line  plots  of  circuit  responses. 
Interactive  operation  (or  extremely  rapid  batch-mode  turnaround)  is  a 
virtual  necessity  for  a  computer-aided  circuit  design  package.   AEDNET 
was  a  great  improvement  over  the  long  turnaround  typical  of  batch  mode 
packages  like  ECAP. 

AEDNET  models  are  composed  of  linear  and  nonlinear  time-varying 
resistors,  capacitors,  inductors,  dependent  and  independent  sources,  and 
special  elements  which  represent  user-written  subroutines.   These  elements 
are  selected  and  connected  graphically  at  the  display  unit,  providing 
highly  symbolic  modeling.   AEDNET  also  provides  a  macro  facility. 
Topological  terminal  subnetworks  can  be  defined  by  equivalent  circuits 
composed  of  basic  elements.   These  subnetworks  can  then  be  represented, 
selected,  and  topologically  interconnected  graphically  in  the  same  fashion 
as  the  pre-defined  elements. 

2.7.3.   ECAP- I I 

ECAP-II  [29]  is  an  advanced  version  of  ECAP  developed  by  Branin 
et.  al.  at  IBM  in  1971.   It  incorporates  nonlinear  analysis  and  macro 
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capabilities.   Nonlinearities  can  be  described  by  tables,  built-in  function 
operators,  and  user-supplied  subroutines.   Topological  terminal  subnetworks 
can  be  constructed  from  basic  elements  and  previously  defined  subnetworks. 
ECAP-II  was  the  first  widely  available  package  to  take  advantage  of  the 
sparse  matrix  structure  typical  of  electrical  circuits  and  many  other  physical 
systems  (see  [30])  and  to  employ  an  implicit  integration  method  tailored 
for  these  typically  stiff  systems  (see  [31]).   These  techniques  significantly 
reduce  running  time,  offering  cheaper  analysis  and  somewhat  faster  turnaround. 

2.7.4.  SCEPTRE 

SCEPTRE  [32],  reported  by  Bowers  and  Sedore  in  1971,  is  quite 
similar  to  ECAP  II.   These  languages  have  essentially  the  same  pre-defined 
elements,  features  for  representing  nonlinearities,  macro  capabilities, 
and  syntax.   SCEPTRE  has  been  applied  in  a  variety  of  disciplines, 
including  pollution  studies  and  biomedical  research,  in  addition  to  electrical 
circuit  analysis  (see  [33]).   In  these  applications  SCEPTRE  integrator 
elements  are  used  to  formulate  state,  equations  as  in  DAS  languages. 
However,  a  single  SCEPTRE  block  can  be  defined  to  represent  many  equations, 
relieving  the  end-user  from  explicitly  stating  each  equation. 

2.7.5.  SUPER*SCEPTRE 

An  advanced  version  of  SCEPTRE,  SUPER*SCEPTRE  [34],  was  reported 
by  Bowers  and  others  at  the  University  of  South  Florida  in  1975.   SUPER*SCEPTRE 
includes  all  features  of  SCEPTRE  and  the  analysis  is  performed  by  the  SCEPTRE 
program.   The  SUPER*SCEPTRE  language  also  incorporates  terminal  models  for 
mechanical  systems,  digital-logic  devices,  control  system  transfer  functions 
and  nonlinear  effects.   In  each  case  a  generous  complement  of  terminal  models 
are  built-in  and  new  ones  can  be  constructed  from  'scratch'  or  from  macro 
subnetworks.   Terminal  models  of  all  types  can  be  combined  conveniently  in 
a  single  model  to  describe  electro-mechanical  and  similar  interdisciplinary 
systems. 

The  preceding  survey  is  representative  of  the  current  state-of- 
the  art,  but  is  not  intended  to  be  complete.   A  brief  list  of  other  modern 
general  purpose  languages  includes  DYNAMO  II  [35] — popular  for  economic 
system  dynamics  but  not  generally  applicable  to  engineering  problems,  SL-I 
[36] — running  only  on  Xerox  installations,  FORSIM  V — a  procedural  FORTRAN 
language  which  supports  partial  differential  equations,  and  SLANG  [38]  and 
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PROSE  [39] — two  languages  developed  at  TRW,  Corp.   There  also  exist  packages 
designed  for  interactive  operation  on  a  dedicated  mini-computer,  such  as 
CSMP  1130  [40],  and  DARE-I  and  II  [41].   These  packages  have  limited 
computational  and  language  features  but  are  very  useful  for  real-time 
simulations . 
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NOTES 


1 

Differential  equations  of  explicit  form  x(t)  =  f(x(t),  t)  are  often 

solved  by  so-called  'implicit'  methods  such  as  predictor-corrector 

methods.   In  these  methods,  an  explicit  predictor,  M  ,  is  used  to 

predict  the  next  values  of  x. 

xP(t  +  At)  =  M  (x(t),  x(t),...) 

—  p  —     — 

after  which  an  'implicit'  corrector,  M  ,  is  used  to  correct  the 
prediction 

x(t  +  At)  =  M];(x(t),  f(xP(t  +  At),  t),...) 

However,  these  methods  are  really  explicit  as  they  can  be  rewritten 
as 

x(t  +  At)  =  M_(x(t),  f(M  (x(t),  x(t),...),  t),...) 
I  —        p  —     — 


2 


3 


4 


which  is  an  explicit  computation. 

Many  packages  allow  the  user  a  choice  of  integration  algorithms.   Some 
of  these  offer  implicit  as  well  as  explicit  methods,  but  require 
explicit  equation  formulations  to  interface  with  the  explicit  methods, 
when  used. 

For  example,  the  nested  sum  A*B+C/D  would  be  specified  as  a  DES-1 
block  input  by  the  expression  SUM(MPY(A,B) ,DIV(C,D) ) . 

In  fact,  this  process  is  quite  time-consuming  even  when  performed 
automatically  by  packages  which  derive  state  equations  for  explicit 
integration.   See  [27],   Furthermore,  explicit  formulation  of  the 
state  equations  is  an  impossible  task  for  general  nonlinear  networks. 
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3.   THE  MODEL  LANGUAGE 

3.1 .   Introduction — Design  Goals  and  Fundamental  Features 

The  development  of  MODEL  was  motivated  by  a  desire  to  extend  the 
power  and  flexibility  of  modern  simulation  languages  in  order  to 

1.  provide  very  general  and  easy  to  use  modeling  features; 

2.  facilitate  computer  aided  network  design  in  a  wide 
variety  of  applications; 

3.  provide  a  convenient  structure  for  hierarchical  models; 

4.  support  different  levels  of  user  sophistication;  and 

5.  offer  a  flexible  environment  for  simulation  studies. 
No  existing  general  purpose  languages  provide  facilities  for  network 
analysis,  while  existing  network  analysis  languages  do  not  provide  the 
convenient  modeling  generality  which  is  desired  to  meet  goals  1  and  2. 
Typically,  network  analysis  languages  impose  restrictions  on  network 
element  types  and  topology  due  to  the  manner  in  which  the  network 
equations  are  formulated.   None  of  these  languages  provides  a  convenient 
facility  for  defining  arbitrary  network  elements  through  user-supplied 
equations.   Those  user-supplied  equations  which  can  be  handled  must  be 
formulated  in  block-oriented  fashion  using  the  available  element  types 
much  as  in  DAS  languages. 

In  order  to  meet  goals  1  and  2,  MODEL  combines  and  extends  the 
most  powerful  modeling  features  of  general  purpose  and  network  analysis 
languages.   MODEL  is  a  general  purpose,  equation-oriented  language  which 
can  also  be  used  in  a  convenient  and  powerful  block-oriented  fashion  for 
a  wide  range  of  specific  network  analysis  applications.   Features  of 
MODEL  incorporated  or  extended  from  modern  general  purpose  languages 
include  generalized  equation-oriented  modeling,  equation-based  macros, 
and  powerful  functional  capabilities.   Facilities  more  commonly  associated 
with  special  purpose  network  analysis  languages  include  topological 
constructs  which  can  be  tailored  for  particular  applications  and  symbolically 
connected  to  construct  network  models  and  (in  the  local  implementation) 
graphical  modeling.   The  provision  of  highly  symbolic  topological  macros 
facilitates  computer  aided  network  design  by  permitting  very  natural 
problem  statements  which  allow  rapid,  high  level  alteration  of  the  network 
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model  during  the  design  process.   The  provision  of  generalized  features 
for  defining  arbitrary  topological  macros  permits  MODEL  to  be  applied  in 
a  specialized  fashion  to  a  wide  range  of  networks,  including  electrical 
circuits,  structural  and  mechanical  systems,  and  network  flow  problems. 
Equation  oriented  modeling  allows  any  initial  value  problems  in  ordinary 
differential  equations  to  be  conveniently  formulated  and  solved  with  MODEL. 

MODEL  facilitates  hierarchical  modeling  by  providing  a  structure 
which  allows  very  simple  conversion  of  macros  into  models  and  vice  versa. 
Models  may  be  structured  into  any  number  of  levels  of  macros  and  any  macro 
can  be  conveniently  adapted  to  stand  alone  as  a  model.   Conversely,  any 
model  may  be  conveniently  used  as  a  macro  in  the  construction  of  higher 
level  models.   MODEL  permits  macro  definitions  to  be  altered  independently 
at  each  level  so  subsystem  models  can  be  refined  and  verified  independently 
in  'bootstrapping'  a  hierarchical  model. 

The  local  implementation  of  MODEL  allows  extensive  libraries  of 
macros  to  be  defined  and  utilized.   This  is  a  convenient  facility  for 
special  purpose  modeling  in  that  topological  macros  for  particular 
applications  need  be  defined  only  once.   Furthermore,  topological  macros 
for  particular  applications  can  be  defined  by  sophisticated  users  for  use 
by  novices.   While  some  equation-oriented  modeling  is  required  to  construct 
basic  topological  macros  for  a  particular  application,  very  little 
sophistication  is  required  to  construct  network  models  from  library  macros. 
When  appropriate  constructs  are  present  in  the  macro  library,  MODEL  can 
take  the  form  of  a  special  purpose  language  in  which  all  modeling  is 
performed  by  interconnecting  highly  symbolic,  predefined  blocks. 

In  general,  MODEL  allows  equation-oriented  and  topological 
modeling  to  be  freely  combined  in  any  macro  or  model.   Topological  macros 
for  different  disciplines  may  be  combined  easily  in  interdisciplinary 
models.   For  example,  a  pressure  meter  can  be  modeled  by  a  topological 
macro  which  interfaces  a  water  pipe  to  an  electrical  control  system. 

MODEL  is  implemented  to  allow  flexibility  in  the  modeling  and 
model  execution  environments.   Two  versions  of  MODEL  will  be  available  soon. 
Tn  the  'local'  version,  MODEL  interfaces  to  the  DRAGON  interactive 
graphical  modeling  and  library  support  package  [1],  which  is  nearing 
completion.   DRAGON  acts  as  a  front-end  to  the  MODEL  compiler,  which  has 
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been  completed.   The  input  to  the  MODEL  compiler  is  completely  text-oriented  and 
the  compiler  itself  is  highly  portable,  as  is  the  numerical  support.   Thus,  a 
nongraphical  version  of  MODEL  can  be  used  at  many  other  installations.   The 
interactive  graphical  version  of  MODEL  allows  macros  and  topological 
connections  to  be  represented  graphically  at  a  remote  terminal.   This 
permits  extremely  symbolic  modeling  which  cannot  be  matched  in  a  text- 
oriented  language.   The  portable  version  of  MODEL  includes  nearly  every 
convenience  of  modern  equation-oriented  and  nongraphical  network  analysis 
languages.   Some  library  support  may  be  provided  as  an  extension  of  the 

portable  version  of  MODEL  in  the  future. 

A  MODEL  simulation  is  controlled  by  a  user-supplied  FORTRAN  program 

which  calls  the  integration  procedure  as  a  subroutine.   This  type  of  run- 
control  was  selected  to  allow  virtually  any  FORTRAN  procedure  to  be  interfaced 
easily  to  a  simulation  study.   The  MODEL  compiler  translates  a  user's  model 
into  FORTRAN,  which  is  also  the  language  employed  for  the  compiler  and 
numerical  support.   The  translation  and  subsequent  simulation  of  a  model  can 
be  accomplished  in  any  fashion  reasonable  for  a  large,  FORTRAN-based  software 
package.   The  package  is  presently  operated  as  a  sequence  of  jobs  or  job 
steps  in  batch  mode.   At  the  local  installation  it  will  soon  be  feasible  to 
invoke  these  steps  on-line  from  a  remote  terminal  and  to  receive  output 
from  the  simulation  while  it  is  in  progress.   The  portable  version  of  MODEL 
could  also  be  used  in  this  fashion  at  other  installations  having  appropriate 
hardware/software  configurations.   Some  preliminary  thought  has  been  given 
to  extending  local  support  to  interactive  operation,  with  run-time 
interpretation  of  run-control  statements.   On-line  or  interactive  simulation 
is  very  desirable  for  computer  aided  design  because  it  permits  rapid 
evaluation  of  design  alternatives. 

MODEL  also  offers  the  user  every  opportunity  to  alter  any  FORTRAN 
interfaces  to  the  simulation  study  without  recompiling  the  model.   MODEL  is 
the  first  simulation  language  to  allow  a  noninteractive  run-control  program 
(the  FORTRAN  run-control  program)  to  be  conveniently  altered  without 
recompiling  the  model  as  well. 

MODEL  is  also  significant  as  the  first  implicit  general  purpose 
language.   The  use  of  an  implicit  integration  method  was  motivated  by 
numerical  considerations  (see  [2]),  but  is  also  highly  desirable  from  the 
language  point  of  view.   MODEL  equations  maybe  formulated  implicitly. 
Together  with  the  use  of  the  differentiation  operator  ('),   this  permits 
a  very  convenient  and  natural  format  for  first  order  ordinary  differential 
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equations.   The  use  of  the  differentiation  operator  is  restricted  only  in 
that  it  must  be  applied  to  variables,  rather  than  to  expressions  or 
derivatives  although  the  organization  of  MODEL  makes  it  feasible  to  handle 
the  derivatives  of  expressions.   Higher  order  derivatives  and  the  derivatives 
of  expressions  are  currently  expressed  through  the  introduction  of  auxiliary 
variables  although  a  routine  extension  to  MODEL  would  allow  these  types  of 
derivatives  to  be  handled  directly.   In  addition  to  allowing  a  freer  equation 
format,  the  use  of  an  implicit  integration  method  makes  the  MODEL  language 
inherently  parallel. 

3.2 .   Graphical  and  Card-Oriented  Modeling 

As  we  have  mentioned,  an  interactive  graphical  version  and  a 
portable  text-oriented  version  of  MODEL  will  soon  be  in  use.   Graphical 
modeling  is  performed  interactively  at  a  remote  terminal  under  the  DRAGON 
support  package  whose  use  is  described  in  [1].   Text-oriented  modeling  is 
described  here  and  in  the  user's  manual  for  MODEL  [3].   Any  differences 
between  the  language  description  given  here  and  that  given  in  [3]  reflect 
changes  in  the  previous  version  of  MODEL  which  will  be  incorporated  into 
our  updated  user's  manual. 

For  the  purpose  of  distinguishing  between  graphical  and  text 
oriented  modeling  features,  we  will  refer  to  the  DRAGON  dialect  and  the 
text  dialect  of  MODEL.   The  principal  differences  between  the  two 
dialects  are  the  manner  in  which  macros  are  represented  and  inserted  into 
a  model,  the  manner  in  which  topologies  are  defined,  and  the  provision  of 
libraries  by  DRAGON.   In  the  DRAGON  dialect,  macros  are  constructed 
interactively  and  represented  by  mnemonic  pictures  such  as  those  shown 
in  Figure  3.1.   Macros  are  inserted  into  a  model  graphically  using 
DRAGON's  extensive  commands  for  positioning  mnemonic  pictures  on  the 
display  screen.   Macro  connection  points,  called  terminals,  and 
connections  between  these  terminals  are  also  expressed  graphically. 
These  features  permit  highly  symbolic  modeling  which  cannot  be  matched 
in  a  text  oriented  language.   In  the  text  dialect,  text  statements  are 
used  to  represent  and  insert  macros  into  a  model  and  to  define  and  connect 
terminals . 

DRAGON  maintains  three  permanent  libraries:  the  element  (or 
macro)  library,  the  terminal  (topology)  type  library,  and  the  FORTRAN 
library.  During  an  interactive  modeling  session,  temporary  libraries 
are  developed  through  selection  of  items  from  the  permanent  libraries  and/or 
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through  user-supplied  definitions.   The  temporary  libraries  are  called  the 
element  menu,  the  terminal  type  menu,  and  the  FORTRAN  menu.   The  items  on 
a  menu  can  be  selected  for  use  in  modeling  by  pointing  at  the  name  of  the 
desired  item  in  the  menu  display  area.   The  entire  FORTRAN  menu  is 
included  in  the  model  automatically.   The  manner  in  which  items  are 
transferred  from  the  permanent  libraries  to  the  menus  and  vice  versa 
is  described  in  [1].   The  definition  and  use  of  menu  items  is  discussed 
here  as  well  as  in  [1] . 

The  only  other  noteworthy  difference  between  the  two  dialects 
of  MODEL  is  the  method  of  identifying  problem  statements.   In  the  DRAGON 
dialect,  the  desired  function  is  selected  graphically.   In  the  text 
dialect,  keywords  are  used  to  indicate  the  statement  type.   With  these 
exceptions  all  modeling  is  text-oriented  in  both  dialects  and  the  syntax 
and  semantics  of  the  text  strings  are  identical.   Very  few  restrictions 
are  placed  on  the  order  of  problem  statements  and  a  free  format  is 
provided  for  all  text-oriented  modeling.   There  are  no  fixed  column 
positions.   Blanks  are  significant  only  as  separators  and  are  otherwise 
ignored . 

The  statements  of  the  text  dialect  of  MODEL  are  listed  in 
Appendix  A,  which  also  describes  the  order  in  which  the  input  file  must 
be  organized  in  the  text  dialect. 
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Figure   3.1.      Mnemonic   pictures   for   topological  macros 
Terminals   are   represented  by  circles   0. 
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3.3.  Overall  Model  Structure — Elements  and  Subelements 

The  MODEL  language  makes  no  distinction  between  macros  and  models. 
In  both  the  DRAGON  and  text  dialects,  models  are  defined  in  exactly  the 
same  fashion  as  macros.   This  lack  of  distinction  has  the  implications  that 
any  model  can  be  easily  added  to  the  DRAGON' s  macro  library  and  any  macro 
can  make  use  of  all  modeling  features  of  the  MODEL  language.   There  are  no 
fixed  limits  on  the  depth  to  which  macros  may  be  nested  or  the  number  of 
macros  which  can  be  employed  in  any  model.   Furthermore,  macro  definitions 
may  be  altered  independently  at  each  level  of  usage.   By  this  we  mean  that 
a  change  in  the  definition  of  macro  M  does  not  necessarily  imply  that  the 
definitions  of  macros  which  invoke  M  or  are  invoked  by  M  must  also  be 
changed.   This  structure  was  chosen  to  facilitate  the  use  of  the  macro 
library,  particularly  for  modeling  hierarchical  systems.   Subsystem 
models  can  quite  easily  be  refined  and  verified  independently  in  'bootstrappini 
a  hierarchical  model. 

In  the  remaining  discussion,  we  will  refer  to  macros  as  'elements'. 
When  discussing  a  particular  element,  it  will  often  be  convenient  to  refer 
to  those  elements  which  it  invokes  as  its  'subelements'.   Topological 
elements  are  also  sometimes  called  'networks' .   We  use  this  nomenclature 
to  avoid  unnecessary  distinction  between  models  and  macros  and  to  emphasize 
the  fact  that  all  models  are  themselves  language  elements  (i.e.,  macros). 

The  MODEL  language  processor  will  expand  any  number  of  element 
references  nested  to  any  depth,  provided  sufficient  core  is  available. 
MODEL  does  not,  however,  provide  a  macro  interpretive  language  to  support 
macro-level  features  such  as  loops,  branches,  and  conditional  expansion. 
Extensive  use  of  features  such  as  these  usually  leads  to  excessive 
compilation  times  and  thus  is  rarely  warranted.   These  features  have  not 
been  implemented  in  MODEL  for  this  reason  and  out  of  an  attempt  to  keep 
core  requirements  to  a  minimum  in  the  language  processor.   A  macro 
interpretive  language  may  be  added  to  MODEL  at  some  future  time. 

3.4 .  Element  Definition 

3.4.1.   Element  Modeling  Sequence — Parameters  and  Default  Values 

In  the  text  dialect,  the  name,  parameters,  and  default  parameter 
values,  if  any,  of  an  element  may  be  defined  in  a  single  statement  of  the 
general  form 
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ELEMENT  e It-name  {parm{(d ,  d  )}{=def-exp] ;}* 

This  statement  begins  the  definition  of  the  element  elt-name .   All  subsequent 
statements  until  the  next  ELEMENT  statement  or  the  end  of  the  element 
definitions  serve  to  define  this  element.   The  statements  within  any  element 
definition  may  appear  in  virtually  any  order.   The  only  restriction  is  that 
statements  which  specify  nondefault  parameter  values  and  connections  for 
a  subelement  must  follow  the  statement  which  invokes  that  subelement .   Each 
statement  type  may  be  used  any  number  of  times.   When  statements  of  the  same 
type  are  grouped  together  within  an  element  definition,  it  is  not  necessary 
to  include  the  keyword  for  each  statement.   Any  statement  which  does  not 
begin  with  a  keyword  is  assumed  to  be  of  the  same  type  as  the  last  previous 
keyword.   When  the  statement  following  an  ELEMENT  statement  does  not  begin 
with  a  keyword,  it  is  assumed  to  be  an  equation  statement.   Elements  may  be 
defined  in  any  order,  regardless  of  the  level  at  which  they  are  invoked. 
Thus,  MODEL  offers  the  most  flexible  text-oriented  modeling  sequence  of 
any  language  presently  available. 

In  the  generalized  ELEMENT  statement  above,  elt-name   is  the  name 
of  the  element  being  defined.   All  names  defined  in  MODEL  must  be 
alphanumeric  strings  of  eight  characters  or  less  and  must  begin  with  a 
letter.   Each  use  of  parm   represents  a  parameter  name.   All  parameters  and 
variables  defined  in  MODEL  are  floating  point  quantities  and  may  be  scalars 
or  arrays  of  one  or  two  dimensions.   Parameters  may  represent  state  or 
auxiliary  variables  whose  behavior  is  specified  by  the  equations  of  the 
element,  or  they  may  represent  adjustable  constants.   The  dimensions  of 
parameter  arrays  are  defined  in  the  form  parm    (d_13    d-)   where  d   and  d  are 
integers.   The  dimensions  may  be  omitted  when  the  parameter  is  a  scalar. 
Default  parameter  assignments  may  be  defined  in  the  form  parm    (d-s   dp)   = 
def-exp.      Default  values  are  typically  constants,  but  def-exp   may  be  any 
well-defined  MODEL  expression  whose  variables  are  known  within  the  element 
elt-name  .  Def-exp   must  have  the  same  dimensions  as  parm.      The  permissible 
forms  for  scalar  and  nonscalar  MODEL  expressions  are  described  in  section 
3.4.5  which  deals  with  MODEL  equations.   Default  parameter  assignments  may 
be  omitted  when  not  desired. 

There  is  no  restriction  on  the  number  of  parameters  an  element  can 
have.   Many  parameter  definitions  can  be  included  in  the  ELEMENT  statement 
separated  by  semicolons.   The  ELEMENT  statement  must  be  a  single  card  image 
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(72  columns),  but  the  DEFAULTS  statement  may  also  be  used  to  define 
additional  parameters.   This  statement  has  the  general  form 

DEFAULTS  {parmUd^,   d^)}{=def-exp};}* 
Any  number  of  DEFAULTS  statements  may  be  used  in  any  element. 

Because  elements  may  be  defined  in  any  order  in  the  text  dialect 
it  is  necessary  for  the  user  to  specify  which  is  the  highest  level  element 
of  the  model  so  the  language  processor  can  begin  the  model  analysis  with 
that  element.   This  is  done  by  the  ANALYZE  statement  which  has  the  form 

ANALYZE  model-name 
where  mode l-name    is  the  name  of  the  highest  level  element.   This  statement 
precedes  the  first  ELEMENT  statement  of  the  input  file.   If  no  ANALYZE 
statement  is  included,  analysis  will  begin  with  the  element  named  in  the 
first  ELEMENT  statement  of  the  input  file. 

In  the  DRAGON  dialect,  an  element  is  defined  at  the  end  of  its 
interactive  construction  process.   The  user  selects  the  SAVE  function  and 
types  in  the  name  by  which  the  element  is  to  be  known,  e.g., 

{SAVE}  name 
This  adds  the  element's  definition  to  the  temporary  library  (called  the 
menu) ,  allowing  it  to  be  used  in  the  construction  of  other  elements  or  to 
be  passed  to  the  language  processor  for  compilation  and  execution.   The 
elements  of  a  model  may  not  be  defined  in  arbitrary  order  in  the  DRAGON 
dialect.   Before  one  element  can  be  used  in  the  construction  of  another 
some  definition  of  the  first  element  must  be  present  in  the  menu.   However, 
in  most  cases  a  lower  level  element  of  a  model  may  be  altered  without 
redefining  the  higher  level  elements  of  the  model.   The  operations  involved 
in  the  construction  of  an  element  can  be  carried  out  in  any  meaningful 
order  and  may  be  repeated  any  number  of  times. 

In  the  DRAGON  dialect,  the  parameters  of  an  element  and  their 
default  values,  if  any,  are  defined  prior  to  SAVEing  the  element  in  the 
menu.   Selection  of  the  PARM  function  allows  the  user  to  type  in  the 
parameter  definitions  in  the  same  format  as  the  DEFAULTS  statement  of  the 
text  dialect.   Any  number  of  text  lines  may  be  entered  without  reselecting 
the  PARM  function. 
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3. A. 2.   Global  and  Local  Variables  and  the  Independent  Variable 

In  addition  to  parameter  sets,  sets  of  global  and  local  variables 
may  be  defined  within  any  element.   These  are  state  and  auxiliary  variables 
whose  behavior  is  modeled  by  equations.   Local  variables  are  specific  to  the 
element  in  which  they  are  defined.   Global  variables  may  be  referenced  in 
the  equations  of  the  element  in  which  they  are  defined  as  well  as  in  the 
equations  of  its  subelements,  their  subelements,  etc.   A  variable  which  is 
declared  as  a  global  in  some  element  E  is  automatically  defined  within  any 
subelements  of  E  and  need  not  be  explicitly  declared  in  those  elements. 
Like  parameters,  local  and  global  variables  may  be  scalars  or  arrays,  and 
no  restrictions  are  placed  on  the  number  of  variables  which  can  be  defined 
in  any  element. 

Variable  scoping  is  a  very  useful  feature  for  hierarchical 
models,  particularly  when  subsystem  models  are  to  be  refined  independently. 
MODEL  allows  the  most  flexible  variable  scoping  of  any  simulation  language. 
Other  general  purpose  languages  assume  that  any  variables  which  appear  in 
the  body  of  a  macro  and  are  not  among  its  parameters  are  local  to  that 
macro.   Thus,  variables  can  have  global  scope  only  if  they  are  parameters 
of  all  macro  invocations. 

In  the  text  dialect,  global  and  local  variables  are  defined  by  the 
GLOBALS  and  LOCALS  statements  whose  general  forms  are  . 

GLOBALS  {global{(d  ,    d)};}* 
LOCALS  {localUd,   d_2)};}* 
Here  global   and  loaal   represent  variable  names  and  the  optional  dimensions 
are  represented  by  (d  ,  d_  )  .   Any  number  of  GLOBALS  and  LOCALS  statements 
may  be  used  in  any  element . 

In  the  DRAGON  dialect,  global  and  local  variables  are  defined  by 
selecting  either  the  GLO  VAR  or  the  LOC  VAR  function  and  typing  in  the 
definitions  in  the  same  format  as  the  GLOBALS  and  LOCALS  statements  of  the 
text  dialect.   Any  number  of  text  lines  may  be  entered  without  reselecting 
the  function. 

The  independent  variable  is  known  by  the  default  name  'TIME'  and 
can  be  referenced  in  the  equations  of  any  element.   The  independent  variable 
can  be  renamed  by  the  statement 

RENAME  ind-var-name 
where  ind-var-name    is  any  legal  MODEL  name  by  which  the  independent  variable 
is  to  be  known.   In  the  text  dialect,  the  RENAME  statement  must  precede  the 
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first  ELEMENT  statement  of  the  input  file.   In  DRAGON,  a  RENAME  statement 
can  be  added  to  the  header  block  of  an  element  by  selecting  the  HEADER 
function  and  typing  the  statement.   When  an  element  is  sent  to  the  MODEL 
compiler,  its  header  block  is  automatically  included  in  the  input  file. 

3.4.3.   Topology — Terminals,  Terminal  Types,  Terminal  Variables,  and 

the  Generalization  of  Kirchoff's  Laws 

Topological  modeling  is  accomplished  through  the  use  of  terminals 
which  represent  the  connection  points  of  an  element.   Terminals  can  be 
used  to  model  a  wide  variety  of  connectors,  including  electrical  and  flow 
problem  junctions  and  structural  and  mechanical  joints.   We  will  begin 
this  discussion  of  topological  modeling  by  considering  the  manner  in 
which  terminals  are  defined,  distinguished,  and  assigned  terminal   types. 
We  will  then  discuss  the  significance  of  the  terminal  variable  sets 
which  are  associated  with  each  terminal  of  a  given  type,  and  the  manner 
in  which  terminal  variable  behavior  is  defined  by  terminal  connections. 
The  manner  in  which  topological  elements  are  connected  into  networks 
is  described  in  the  next  section. 

Terminals  may  be  either  external   or  local   in  scope.   Local 
terminals  represent  intra-element  connection  points.   The  local  terminals 
of  an  element  may  be  connected  only  within  the  definition  or  construction 
of  that  element.   External  terminals  represent  inter-element  connection 
points.   When  a  subelement  is  invoked,  each  of  its  external  terminals  is 
connected  to  some  terminal  in  the  invoking  element.   Local  and  external 
terminals  may  be  freely  interconnected  any  number  of  times  within  any 
element.   The  external  terminals  of  an  element  allow  it  to  be  connected 
as  a  subelement.   Local  terminals  provide  a  flexible  means  of  connecting 
the  external  terminals  of  subelements  into  a  network.   In  DRAGON,  local 
terminals  can  also  enhance  clarity  in  the  graphical  representation  of  an 
element.   If  this  mnemonic  picture  is  complex,  it  may  be  inconvenient  to 
represent  a  desired  connection  in  the  usual  fashion  as  a  straight  line 
between  two  terminals.   A  connection  line  which  would  otherwise  pass 
through  some  part  of  the  picture  can  be  rerouted  by  the  introduction  of 
local  terminals. 

Each  terminal  within  an  element  is  distinguished  by  a  unique 
integer  called  its  terminal  ID  number.   Terminal  ID  numbers  provide  the 
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means  of  distinguishing  terminal  variable  references  in  the  equations  of 
the  element .   In  the  text  dialect ,  terminal  ID  numbers  also  provide  the 
means  of  distinguishing  terminal  references  in  connection  statements. 

In  the  text  dialect,  terminals  are  defined  by  the  TERMINALS 
statement.   This  statement  defines  terminals  with  local  scope.   Defined 
terminals  are  given  external  scope  by  the  EXTERNALS  statement.   The  basic 
formats  of  these  statements  are  the  same.   Terminals  are  identified  by 
ID  number  and  may  be  referenced  singly,  e.g. 

TERMINALS  1 
;  in  consecutively  numbered  groups,  e.g., 

EXTERNALS  2-5 
;  or  in  any  combination  of  these  fashions,  e.g., 

TERMINALS  2-5  10  6-8 
EXTERNALS  statements  may  appear  either  before  or  after  the  TERMINALS 
statements  which  define  the  terminals.   Terminals  need  not  be  defined  in 
the  order  of  their  ID  numbers  and  the  set  of  terminal  ID  numbers  defined 
within  an  element  need  not  be  consecutive. 

In  the  DRAGON  dialect,  selection  of  the  TERM  function  allows 
the  user  to  define  terminals  by  pointing  at  the  positions  on  the  screen 
where  terminals  are  desired.   This  causes  the  terminals  to  be  displayed 
graphically  as  small  circles  (0) ,  and  to  be  assigned  ID  numbers  which  can 
be  displayed  alongside  the  terminals.   External  terminals  are  specified 
by  selecting  the  MAKEX  command  and  pointing  at  the  terminals  which  are  to 
have  external  scope. 

MODEL  imposes  no  fixed  limits  on  the  number  of  local  or  external 
terminals  which  can  be  defined  in  any  element. 

We  have  mentioned  that  MODEL  terminals  can  be  used  to  model  a 
wide  variety  of  connectors.   This  variety  is  accommodated  by  allowing  the 
terminal   type   of  each  terminal  to  be  selected  from  DRAGON 's  library  of 
terminal  types  or  defined  by  the  user.   We  will  first  describe  the  manner 
in  which  terminal  types  are  associated  with  the  terminals  of  an  element, 
and  then  discuss  the  definition  and  significance  of  terminal  types. 

In  the  text  dialect,  a  terminal  type  may  optionally  be  associated 
with  each  group  of  terminal  ID  numbers  defined  in  a  TERMINALS  statement. 
Thus,  the  general  form  of  the  TERMINALS  statement  is 

TERMINALS  {te rm- no-te rrn- no  type } * 
where  type   represents  the  terminal  type  name.   For  example,  suppose  CONTROL 
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is  the  name  of  a  terminal  type  which  models  an  electrical  control  junction 
and  FLUID  is  the  name  of  a  terminal  type  which  models  a  junction  in  a  flow 
network.   Then  the  statement 

TERMINALS  1  CONTROL  2  3  FLUID 
would  define  terminal  1  with  type  CONTROL,  terminal  3  with  type  FLUID,  and 
terminal  2  with  undefined  type. 

In  the  DRAGON  dialect,  selection  of  the  ASG  TYPES  function  allows 
the  user  to  select  a  terminal  type  from  the  menu  and  associate  this  type 
with  terminals  of  the  element  under  construction  by  pointing  at  the 
desired  terminals. 

In  either  dialect,  it  is  not  necessary  to  define  the  type  of 
every  terminal.   Connections  between  terminals  of  different  types  are  not 
allowed  so  the  MODEL  language  processor  can  determine  the  types  of  most 
terminals  from  the  types  of  terminals  to  which  they  are  connected.   A 
terminal's  type  will  be  undetermined  only  if  no  terminal  to  which  it  is 
connected,  either  directly  or  indirectly,  has  been  assigned  a  type. 

The  definition  of  a  terminal  type  consists  of  the  specification 
of  its  terminal  type  name  and  of  the  sets  of  terminal  variables  which  are 
to  be  associated  with  each  terminal  of  that  type.   The  terminal  variables 
represent  generalizations  of  Kirchoff's  voltage  and  current  laws  and  hence 
are  divided  into  two  sets,  called  the  E-set  and  the  I-set.   Terminal 
variables  are  automatically  'transmitted'  through  terminal  connections. 
E-type  terminal  variables  (the  members  of  the  E-set)  act  like  voltages 
transmitted  through  connections.   Each  variable  of  the  E-set  automatically 
assumes  the  same  value  at  all  terminals  connected  in  a  common  node.   I-type 
terminal  variables  act  like  currents  transmitted  into  an  element  through 
its  external  terminals  and  transmitted  out  of  an  element  through  the 
external  terminals  of  its  subelements.   Under  this  sign  convention  each 
variable  of  the  I-set  automatically  sums  to  zero  over  all  terminals 
connected  in  a  common  node.   This  insures  that  I-type  variables  (e.g., 
currents)  do  not  accumulate  at  any  node. 

MODEL  imposes  no  restrictions  on  the  number  of  terminal  types 
which  can  be  defined  or  the  number  which  can  be  used  within  any  element. 

In  the  text  dialect,  terminal  types  are  defined  by  TYPE 
statements  which  precede  the  first  ELEMENT  statement  of  the  input  file. 
These  statements  serve  to  define  terminal  types  for  use  within  the  elements 
in  the  input  file. 


77 


In  the  DRAGON  dialect,  terminal  types  are  defined  by  selecting 
the  MOD  TYPES  command  and  typing  in  the  definition.   This  adds  the  terminal 
type  to  the  menu  and  allows  it  to  be  selected  for  use  via  the  ASG  TYPES 
command  which  we  have  previously  described. 

The  format  for  terminal  type  definitions  is  the  same  in  both 
dialects.   The  general  form  in  the  text  dialect  is 

TYPE  type-name  E({ename{(d  3   dj};}*)    l({iname{  (d  3   dj};}*) 
type-name   represents  the  name  of  the  terminal  type,  ename   and  iname 
represent  a  terminal  variable  name.   The  dimensions  of  the  terminal 
variables  represented  by  (d  ,  d~)  are  optional  and  may  be  omitted  for 
scalar  variables.   The  terminal  type  definition  must  be  a  single  card 
image,  but  otherwise  MODEL  imposes  no  restrictions  on  the  number  of 
terminal  variables  which  can  be  associated  with  any  terminal  type.   Either 
the  E-set  or  the  I-set  may  be  omitted  if  no  terminal  variables  of  one  type 
are  required. 

The  TYPE  statements  of  Figure  3.2  illustrate  the  terminal  type 
definition  format  and  the  use  of  E-type  and  I-type  terminal  variables  to 
represent  various  network  junction  effects.   The  symbol  %  denotes  comment 
text . 

MODEL  is  the  first  language  to  generalize  the  application  of 
Kirchoff's  laws  which  are  common  network  principles.   The  automatic 
imposition  of  these  laws  at  each  node  of  the  network  offers  the  convenience 
of  topological  modeling  in  a  wide  variety  of  applications.   Terminal 
variables  can  be  used  to  model  junction  effects  such  as  deflections, 
forces,  stresses,  strains,  pressures,  flow  rates,  and  many  more.   Topo- 
logical modeling  is  conceptually  simplified  by  allowing  symbolic  names  to 
be  selected  for  terminal  types  and  terminal  variables.   Interdisciplinary 
modeling  is  facilitated  by  allowing  the  definition  and  use  of  any  number 
of  terminal  types.   Generality  is  provided  by  allowing  terminal  variable 
behavior  to  be  defined  by  user-written  equations  as  well  as  by  the 
automatic  application  of  Kirchoff's  laws.   Equation  modeling  of  terminal 
variables  will  be  illustrated  in  section  3.4.5.   First,  we  will  discuss 
the  invocation  and  connection  of  subelements. 
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%  ELECTRICAL  JUNCTION 

TYPE  ELECTRIC  E (VOLTAGE)  I (CURRENT) 
%  FLUID  JUNCTION 

TYPE  FLUID  E (PRESSURE)  I (FLOW) 
%  CONTROL  JUNCTION 

TYPE  CONTROL  E (LEVEL) 

%  STRUCTURAL  PIN  JOINT: MODELED  IN  TERMS  OF 
%  FORCES  AND  DEFLECTIONS  IN  THREE  DIMENSIONS 

TYPE  PINJOINT  E(DEFLX;DEFLY;DEFLZ)  I (FORCEX; FORCE Y ;FORCEZ) 

%  STRUCTURAL  JOINT :MODELED  IN  TERMS  OF  STRESS 

%  AND  STRAIN  TENSORS  IN  TWO  DIMENSIONS. 

%    STRESS  (l)«-a  STRAIN  (1H£ 

x  x 

%    STRESS  (2)«-a  STRAIN (2)«-€ 

y  y 

%    STRESS  (3)<-t    (SHEAR)         STRAIN  (3)+-  Y   (SHEAR  STRAIN) 
TYPE  S JOINT  E (STRESS (3))  I (STRAIN (3)) 

Figure  3.2.   Terminal  type  definitions. 


79 


3.4.4.   Connections  and  Subelement  Invocation 

Intra-element  connections  are  specified  differently  than 
inter-element  connections  in  both  dialects  of  MODEL.   We  will  first 
discuss  intra-element  connections — that  is,  connections  between  the 
local  and  external  terminals  of  a  single  element.   Then  we  will  consider 
the  manner  in  which  subelements  are  invoked  and  connected  into  a  network. 

In  the  text  dialect,  intra-element  connections  are  specified 
by  the  CONNECT  statement  which  has  the  general  form 

CONNECT  { tevm-no  -   term-no}* 

In  the  DRAGON  dialect,  intra-element  connections  are  specified 
by  selecting  the  CONNECT  function  and  pointing  at  the  pairs  of  terminals 
to  be  connected.   Connections  appear  on  the  screen  as  a  straight  line 
joining  the  two  terminals. 

In  both  dialects,  the  local  and  external  terminals  of  any 
element  may  be  freely  interconnected  with  no  topological  restrictions. 

In  the  text  dialect,  subelements  are  invoked  by  the  SUB-ELEMENT 
statement  which  has  the  general  form 

SUB-ELEMENT  sub-elt-name   {parm=expj}* 
sub -e It-name    is  the  name  of  the  element  to  be  invoked.   The  pavm=exp 
represent  a  sequence  of  nondefault  parameter  assignments  for  the  subelement, 
They  may  be  specified  in  any  order.   Parameter  assignments  can  be  any  well- 
defined  MODEL  expressions  whose  variables  are  known  within  the  invoking 
element.   Parameter  assignments  can  be  omitted  when  default  values  are 
defined.   A  single  SUB-ELEMENT  statement  is  used  for  each  subelement 
invocation.   When  many  parameter  assignments  are  needed,  the  NON-DEFAULTS 
statement  can  also  be  used.   This  is  the  complement  of  the  DEFAULTS 
statement  and  has  the  general  form 

NON-DEFAULTS  {parm=exp$ * 
where  parm   represents  a  parameter  name  and  exp    represents  the  expression 
whose  value  is  to  be  assigned  to  that  parameter.   Parameter  values  may  be 
assigned  in  any  order  in  the  NON-DEFAULTS  statement.   Any  parameters  which 
are  not  assigned  values  in  SUB-ELEMENT  and  NON-DEFAULTS  statements  will 
assume  their  default  values  if  these  are  defined. 

In  order  to  accommodate  multiple  invocations  of  the  same  element, 
each  NON-DEFAULTS  statement  must  follow  the  SUB-ELEMENTS  statement  to  which 
it  refers  and  no  other  SUB-ELEMENT  statements  may  intercede. 
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The  use  of  the  ELEMENTS,  DEFAULTS,  SUB-ELEMENT,  and  NON-DEFAULTS 
statements  is  illustrated  in  the  following  example.   The  element  EX  has 
parameters  which  are  defined  by  the  statements 

ELEMENT  EX  PI  ;P2=5  ;P3  (4  ,4) 

DEFAULTS  P4=4;P5 
It  is  invoked  by  an  element  which  includes  the  statements 

LOCALS  X;Y;A(4,4) 

SUB-ELEMENT  EX  P1=X+Y;P3=A 

NON-DEFAULTS  P5=21 
For  this  invocation  of  EX,  PI  will  be  replaced  by  X+Y .   P2  and 
P4  will  be  replaced  by  their  default  values,  5  and  4,  respectively.   P3 
will  be  replaced  by  A  which  might  be  an  array  of  state  variables  whose 
behavior  is  defined  by  EX.   P5  will  be  replaced  by  21. 

In  the  DRAGON  dialect,  subelements  are  invoked  by  pointing  at 
the  desired  element  name  in  the  menu  and  then  pointing  at  the  terminals 
to  which  the  subelement  is  to  be  connected  in  the  proper  sequence.   The 
subelemenr's  graphical  representation  will  then  be  displayed  between  the 
terminals  to  which  it  is  connected.   Local  terminals  can  be  defined  by 
pointing  at  vacant  areas  of  the  screen  rather  than  existing  terminals. 
If  the  subelement  has  no  external  terminals,  the  user  points  at  the  area 
of  the  screen  where  the  subelement' s.  graphical  representation  (which  may 
be  only  its  name)  is  to  appear,  and  no  terminals  are  defined.   Parameter 
assignments  for  the  subelement  are  specified  by  selecting  the  CH  PARMS 
command.   This  displays  the  list  of  default  parameter  assignments  for  the 
subelement  which  was  entered  via  the  PARMS  command.   To  change  a  default 
assignment  the  user  points  at  and  then  retypes  the  text  line  in  question. 
As  in  the  text  dialect,  the  nondefault  parameter  assignments  may  be  any 
expressions  involving  variables  and  parameters  of  the  invoking  element 
and  global  variables. 

In  the  text  dialect,  subelements  are  connected  into  a  network  by 
the  SUB-CONNECT  statement.   This  statement  has  the  general  form 

SUB-CONNECT  { term-no}* 
The  term-no   represents  the  ID  numbers  of  the  terminals  in  the  invoking 
element  to  which  the  subelement  is  to  be  connected.   Their  order  corresponds 
to  the  order  in  which  the  external  terminals  of  the  subelement  are  defined 
in  its  TERMINALS  statements.   Like  the  NON-DEFAULTS  statement  the  SUB-CONNECT 
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statement  must  follow  the  corresponding  SUB-ELEMENT  statement  with  no  other 
SUB-ELEMENT  statements  interceding. 

In  both  dialects  of  MODEL,  subelements  may  be  freely  inter- 
connected through  the  terminals  of  the  invoking  element .   MODEL  imposes  no 
restrictions  on  inter-element  topology.   Many  network  analysis  packages 
impose  such  restrictions  due  to  the  manner  in  which  they  formulate  the  network 
equations.   Most  network  analysis  packages  formulate  explicit  state 
equations  from  the  network  topology  by  matrix  methods.   Many  of  these 
packages  cannot  integrate  topologies  which  involve  equivalent  state 
variables  (parallel  capacitors  and  serial  inductors  are  frequent  examples 
in  electrical  circuit  analysis)  because  of  resulting  matrix  singularities. 
MODEL  determines  the  state  variables  symbolically  from  the  tableau  of 
implicit  equations,  and  (together  with  its  associated  numerical  software) 
automatically  removes  equivalent  variables  and  redundant  equations.   Thus, 
there  is  no  problem  with  matrix  singularities  due  to  equivalent  state 
variables,  either  in  the  state  formulation  or  in  the  integration. 

The  SUB-CONNECT  statement  can  also  be  used  to  establish  pseudo-ID 
numbers  for  the  external  terminals  of  subelements.   This  would  be  done  to 
allow  the  equations  of  the  invoking  element  to  reference  I-set  variables  at 
these  terminals.   References  to  E-set  variables  do  not  present  the  same 
problem  because  these  variables  assume  the  same  value  at  the  terminal  to 
which  they  are  connected.   However,  when  two  or  more  external  subelement 
terminals  are  connected  to  the  same  local  terminal  (which  is  typically  the 
case) ,  a  reference  to  an  I-set  variable  at  that  terminal  would  not  be 
well-defined.   References  to  I-set  variables  at  local  terminals  are  not 
allowed  due  to  the  lack  of  a  convenient  convention  for  the  direction  of 
flow  at  these  terminals.   Thus,  it  may  be  necessary  to  reference  an  I-set 
variable  at  an  external  subelement  terminal.   A  pseudo-ID  number  to  be 
used  for  such  a  reference  can  be  defined  by  attaching  it  to  the  ID  number 
of  the  connected  terminal  in  the  SUB-CONNECT  statement.   For  example, 

SUB-CONNECT  3  4-1  2 
establishes  -1  as  the  pseudo-ID  number  of  the  second  external  terminal 
of  subelement  EX.   In  the  DRAGON  dialect  the  PSID  function  can  be  used  to 
establish  and  display  a  pseudo-ID  number.   After  selecting  the  PSID  function 
the  user  identifies  the  external  subelement  terminal  by  pointing  at  the 
connected  local  terminal  and  typing  the  subelement  name.   A  generated  pseudo- 
ID  number  will  then  appear  on  the  screen. 
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An  experimental  feature  of  the  text  dialect  is  the  strip 
terminal.      Strip  terminals  allow  elements  to  be  used  with  a  variable 
number  of  external  connections  without  shorting  any  connections  together. 
This  feature  is  provided  for  modeling  elements  which  have  a  variable 
number  of  input  lines  such  as  the  voltage  summer  of  Figure  3.3.   The  use 
of  the  strip  terminal  allows  the  voltage  summer  to  be  modeled  by  a  single 
element  regardless  of  the  number  of  input  lines  used  in  each  invocation. 
Any  number  of  terminals  may  be  directly  connected  to  an  external  strip 
terminal  of  a  subelement .   Each  such  connection  causes  MODEL  to  generate 
a  terminal  within  the  subelement  to  receive  the  connection. 

Strip  terminals  are  defined  in  the  TERMINALS  statement  by 
prefixing  their  ID  numbers  with  the  letter  S,  i.e., 

TERMINALS  SI  2  3 
Strip  terminals  always  have  external  scope  and  need  not  be  declared  as 
external  in  an  EXTERNALS  statement. 

The  external  strip  terminals  of  a  subelement  are  connected  into 
a  network  by  CONNECT  statements  in  the  invoking  element.   To  permit  these 
terminals  to  be  identified  in  CONNECT  statements  it  is  necessary  to  define 
a  unique  pseudo-ID  number  for  each  strip  terminal  invoked  by  an  element. 
This  is  done  in  the  SUB-CONNECT  statements  by  entering  Sn  in  place  of  a 
connection  to  the  invoking  element.   For  example,  the  statement 

SUB-CONNECT  S7  1  2 
specifies  that  the  first  external  terminal  of  subelement  SUMMER  is  a  strip 
terminal  which  will  be  referenced  in  the  CONNECT  statements  of  the  invoking 
element  as  terminal  number  7. 

The  SUB-CONNECT  statement  does  not  define  a  connection  to  the 
external  strip  terminal  of  SUMMER  as  it  does  for  the  other  two  external 
terminals.   Connections  to  the  strip  terminal  are  specified  in  CONNECT 
statements  of  the  invoking  element.   The  statement 

CONNECT  3-7  4-7  5-7  6-7 
causes  the  generation  of  four  external  terminals  in  subelement  SUMMER. 
These  terminals  are  connected  to  terminals  3,  4,  5,  and  6,  respectively,  of 
the  invoking  element.   This  is  illustrated  in  Figure  3.3b. 

Connections  between  two  strip  terminals  or  between  a  strip 
terminal  and  another  terminal  of  the  same  element  are  not  allowed. 
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2 
-O 

3 
-O 


TERMINALS  SI  CONTROL  2:3  CONTROL 

EXTERNALS  2:3 

EQUATIONS  LEVEL(2)=MAX(LEVEL(1)) 

LEVEL(3)=SUM(NSTRIP(1) ,LEVEL(1)) 


Figure  3.3a.   Voltage  summer  modeled  by  the  statements 


SUB-ELEMENT  SUMMER 
SUB-CONNECT  S7  1  2 
CONNECT  3-7  4-7  5-7  6-7 


Figure  3.3b.   Voltage  summer  connected  into  a  network  by  the  statements. 


Figure  3.3.   Voltage  summer  ({}  represents  the  strip  terminal).* 

*The  strip  terminal  is  not  presently  supported  by  DRAGON.   Thus,  the 
figures  above  represent  conceptualizations  of  the  voltage  summer,  rather 
than  mnemonic  pictures  constructed  with  DRAGON. 
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For  strip  terminals  to  be  useful  there  must  be  some  special 
operators  available  for  referencing  the  generated  terminals  in  the  equations 
of  the  subelement.   We  will  continue  the  example  of  a  voltage  summer  to 
illustrate  the  possibilities  which  presently  exist. 

The  element  SUMMER  has  three  external  terminals,  defined  by 
the  statements 

TYPE  CONTROL  E (LEVEL) 

TERMINALS  SI  CONTROL  2:3  CONTROL 

EXTERNALS  2:3 
The  input  lines  are  connected  to  the  strip  terminal.   External  terminals 
2  and  3  transmit  the  maximum  and  the  sum,  respectively,  of  the  input 
levels.   This  can  be  expressed  in  the  equations  of  SUMMER  in  the  form 

LEVEL ( 2 ) =MAX (LEVEL ( 1 ) ) 
LEVEL (3 )=SUM (NSTRIP (1), LEVEL (1)) 
References  to  strip  terminal  variables  such  as  LEVEL (1)  are  treated  in  a 
special  way  when  they  appear  as  function  arguments.   If  subelement  SUMMER 
is  connected  by  the  statements 

SUB-CONNECT  S7  1  2 
CONNECT  3-7  4-7  5-7  6-7 
then  LEVEL(l)  will  be  replaced  in  the  argument  list  above  by  the  sequence 
of  arguments 

LEVEL(3) ,LEVEL(4) ,LEVEL(5) ,LEVEL(6) 
Here  3,  4,  5,  and  6  are  the  ID  numbers  of  the  terminals  generated  by  the 
connection  of  terminals  3,  4,  5,  and  6  of  the  invoking  element  to  the 
external  strip  terminal  of  SUMMER.   In  the  first  equation  above,  MAX  refers 
to  the  built-in  FORTRAN  library  function  for  the  maximum  of  a  variable 
number  of  arguments.   In  the  second  equation,  SUM  refers  to  a  user-written 
FORTRAN  function  subroutine  which  forms  the  sum  of  a  variable  number  of 
arguments.   NSTRIP  is  a  built-in  operator  whose  value  is  the  number  of 
terminals  directly  connected  to  a  strip  terminal.   In  this  case,  strip 
terminal  1  has  four  direct  connections  in  the  invoking  element  so  NSTRIP (1) 
is  four.   It  is  used  to  indicate  the  number  of  actual  arguments  in  each 
reference  to  SUM.   The  second  equation  also  illustrates  that  other 
arguments  may  precede  (or  follow)  a  reference  to  a  set  of  generated 
terminal  variables. 
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MODEL  is  the  first  network  analysis  language  to  provide  a  strip 
terminal.   In  other  languages,  a  variable  number  of  input  lines  can  be 
modeled  only  by  defining  many  external  terminals  and  connecting  only  as 
many  as  are  needed  in  each  invocation.   This  method  can  be  used  in  MODEL 
as  well.   E-set  and  I-set  variables  are  set  to  zero  at  unconnected 
terminals.   Strip  terminals  could  prove  to  be  a  great  convenience  where 
applicable.   The  use  of  a  strip  terminal  could  avoid  the  necessity  of 
defining  a  different  version  of  an  element  for  each  number  of  input  lines 
which  might  be  employed.   However,  the  present  features  for  referencing 
strip  terminal  variables  are  only  rudimentary.   This  would  be  an 
appropriate  area  for  future  development  of  MODEL,  perhaps  as  a  subset 
of  a  macro  (element)-interpretive  language. 

3.4.5.   Equations 

MODEL  allows  the  equations  of  each  element  to  be  formulated 
implicitly.   By  this  we  mean  that  the  general  form  of  an  equation  is  simply 

where  eccp      and  expr    represent  arbitrary  algebraic  or  first  order  ordinary 
differential  expressions  involving  constants,  variables,  and  parameters 
known  within  the  element  and  built-in  and  user-defined  operators. 
(Parameter  assignments  are  a  special  case  of  this  form  in  which  the  left 
hand  side  is  a  single  parameter.)   There  is  no  need  for  the  user  to  derive 
an  explicit  state  formulation.   As  the  first  implicit  equation-oriented 
language,  MODEL  offers  the  most  flexible  and  convenient  format  for 
equations  of  any  existing  language.   MODEL  is  also  the  first  language  to 
allow  the  differentiation  operator  (')  to  be  embedded  freely  in  expressions. 
This  obviates  the  necessity  of  introducing  auxiliary  variables  in  order  to 
reference  state  derivatives  as  one  must  in  explicit  languages.   Any 
algebraic  or  first  order  ordinary  differential  equation  which  represents 
a  desired  relationship  between  problem  variables  and  parameters  can  be 
entered  directly.   It  is  presently  necessary  to  introduce  auxiliary 
variables  to  represent  higher  order  derivatives  and  the  derivatives  of 
expressions,  but  a  routine  extension  of  MODEL  would  allow  the  differentiation 
operator  to  be  applied  to  derivatives  and  expressions  as  well  as  to 
variables  and  parameters. 
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In  addition  to  allowing  a  very  flexible  equation  format,  the 
use  of  an  implicit  integration  method  means  that  no  special  operator  is 
needed  to  solve  implicit  equations.   Furthermore,  the  set  of  equations 
need  not  even  be  sortable — that  is,  algebraic  loops  may  be  present  as 
is  often  the  case  in  complex  network  problems.   Thus,  MODEL  can  be  used 
to  solve  a  larger  class  of  problems  than  can  explicit  languages. 

The  operators  which  can  be  used  in  MODEL  equations  and  parameter 
assignments  are  the  differentiation  operator,  standard  infix  operators 
for  scalar  and  array  arithmetic,  built-in  functions,  and  functions 
defined  by  the  user  or  selected  from  the  DRAGON  library.   All  of  these 
operators  can  be  freely  embedded  in  expressions  and,  with  the  above- 
mentioned  restriction  on  the  use  of  the  differentiation  operator,  all 
can  be  freely  nested  to  any  level  of  parenthesis. 

The  operators  available  in  MODEL  are  listed  in  Figure  3.4  along 
with  the  precedences  which  determine  the  ordering  of  operations  in 
expression  evaluation.   Arithmetic  expressions  are  evaluated  in  the 
usual  order  (the  same  as  FORTRAN) .   Parentheses  may  be  freely  inserted 
to  change  the  order  of  evaluation.   Built-in,  user-defined,  and  MODEL 
library  functions  all  have  the  same  precedences  and  are  grouped  together 
under  the  heading  'functions'.   The  built-in  functions  are'  listed  in 
Figure  3.5.   User-defined  functions  are  discussed  in  section  3.5.   The 
relational  and  logical  operators  <,  >,  &,  and  |,  will  be  discussed  in 
section  3.4.6  which  deals  with  the  logical  switching  of  equations. 

MODEL  is  the  first  language  to  provide  infix  operators  for  the 
common  array  operations  of  addition  (+) ,  subtraction  (-) ,  multiplication 
(*) ,  and  inner  product  (.).   FORTRAN  functions  defined  by  the  user  or 
selected  from  the  DRAGON  library  can  also  operate  on  arrays,  as  can  the 
differentiation  operator.   Dimensioned  expressions  involving  array 
variables  and  operators  may  be  embedded  in  any  equation.   For  example, 
if  F  is  a  4  x  4  array  of  coefficients  and  X  is  a  4  x  1  state  vector, 
then  the  single  array  equation 

X'  =  F*X 
can  be  used  in  place  of  the  four  associated  scalar  equations.   MODEL  does 
not  presently  support  array  indexing  in  equations.   The  equations  must 
operate  on  arrays  as  indivisible  entities.   A  routine  extension  of  MODEL 
would  permit  indexing  in  equations.   Indexing  is  presently  possible  at  the 
FORTRAN  level  in  the  run-control  program  and  FORTRAN  function  programs. 
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Figure  3.4.   MODEL  operators  and  precedences. 


*The  differentiation  operator  can  presently  be  applied  only  to  variables  and 
parameters  and  thus  is  implemented  as  a  suffix  to  the  variable  or  parameter 
name . 

**The  unary+  and  right  parenthesis  operators  are  never  placed  on  the 
operator  stack. 

The  input  and  stack  precedences  have  usual  meanings.   In  parsing 
equation  syntax,  each  operator  is  stacked  as  it  is  read  and  removed  from  the 
stack  when  all  of  its  operands  are  known.   If  the  input  precedence  of  the 
operator  being  parsed  is  higher  than  the  stack  precedence  of  the  operator 
on  top  of  the  stack,  the  input  operation  takes  precedence  and  its  result  is 
an  operand  of  the  stack  operator.   The  input  operator  is  simply  pushed  on  top 
of  the  stack.   Thus,  A+B*C  means  A+(B*C)  and  -A**B  means  -(A**B).   If  the 
stack  precedence  is  greater  than  or  equal  to  the  input  precedence,  the  stack 
operation  takes  precedence.   Operators  are  popped  from  the  stack  until  the 
stack  precedence  becomes  less  than  the  input  precedence.   The  input  operator 
is  then  pushed  on  top  of  the  stack.   Thus,  A*B+C  means  (A*B)+C  and  A**B*C 
means  (A**B)*C.   If  the  stack  and  input  precedences  of  an  operator  are  the 
same  (i.e.,  *)  ,  the  operator  associates  left  to  right.   If  the  stack 
precedence  of  an  operator  is  less  than  its  input  precedence  (i.e.,  **)  ,  the 
operator  associates  right  to  left. 
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function  name 


corresponding  FORTRAN 


■-  ■          iiuiaiy  j-uiiui-luu 

LOG 

DLOG 

EXP 

DEXP 

SQRT 

DSQRT 

ATAN 

DATAN 

ABS 

DABS 

COS 

DCOS 

SIN 

DSIN 

MAX 

DMAX1 

MIN 

DMIN1 

SQUARE 

STEP 

description 


natural  logarithm  of  the  argument 

e  raised  by  the  argument 

positive  square  root  of  the  argument 

arc  tangent  (in  radians)  of  the 

argument 

absolute  value  of  the  argument 

cosine  of  the  argument  (in  radians) 

sine  of  the  argument  (in  radians) 

maximum  of  the  arguments 

minimum  of  the  arguments 

square  of  the  argument 

Step  function 


Figure  3.5.   MODEL  built-in  functions. 
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The  equations  may  reference  any  terminal  variable  associated 
with  any  terminal  of  the  element  with  the  exception  of  I-set  variables 
at  local  terminals.   Terminal  variables  are  identified  by  the  variable 
name  followed  by  the  terminal  ID  number  in  parentheses,  i.e.,  FL0W(2) . 
If  FLOW  is  an  I-set  variable,  FLOW (2)  is  the  rate  of  flow  directed  into 
the  element  at  external  terminal  number  2.   If  the  value  of  FL0W(2)  is 
negative,  the  simulated  fluid  is  flowing  out  of  the  element.   When  a 
pseudo-ID  number  is  used  to  reference  an  I-set  variable  at  an  external 
terminal  of  a  subelement,  the  direction  convention  is  the  same — the 
I-set  variables  represent  rates  of  flow  directed  into  the  subelement. 
Thus,  if  -2  is  the  pseudo-ID  number  of  an  external  subelement  terminal, 
FL0W(-2)  is  positive  if  simulated  fluid  is  flowing  into  the  subelement, 
and  is  negative  if  the  flow  is  out  of  the  subelement  (and  thus  into  the 
invoking  element) . 

In  the  text  dialect,  equations  are  entered  by  the  EQUATIONS 
statement  which  has  the  general  form 

EQUATIONS  {exp  =expr; } 
If  the  EQUATIONS  statement  is  the  first  statement  within  the  element 
definition,  it  is  not  necessary  to  include  the  keyword  EQUATIONS.   This 
permits  elements  which  include  only  equations  to  be  defined  with  a  minimum 
of  effort. 

In  the  DRAGON  dialect,  equations  are  entered  by  selecting  the 
EQUATIONS  function  and  typing  in  the  equations. 

In  any  well-defined  model,  there  will  be  one  equation  for  each 
variable  present.   The  variables  of  a  model  consist  of  the  global  and 
local  variables,  parameters,  and  terminal  variables  of  each  element  which 
is  invoked.   In  general,  each  element  should  include  one  equation  for  each 
global  and  local  variable  defined  in  the  element.   In  some  cases  a  variable 
is  defined  in  one  element  while  its  behavior  is  defined  by  an  equation 
of  a  subelement  which  references  it  as  a  global  variable  or  is  invoked 
with  it  as  a  parameter.   The  behavior  of  parameters  is  frequently  defined 
by  the  parameter  assignments  used  in  invoking  the  element  (i.e.,  P=5, 
P=X+Y*Z) .   Sometimes  a  parameter  represents  a  state  or  auxiliary  variable 
whose  behavior  is  defined  by  an  equation  of  the  element.   In  these  cases, 
the  parameter  will  simply  be  replaced  by  a  variable  of  the  invoking 
element  (i.e.,  P=X)  and  the  invoked  element  will  include  an  additional 
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equation  which  defines  the  parameter's  behavior.   The  parameters  of  the 
highest  level  element  of  the  model  are  assigned  values  in  the  run-control 
language . 

As  concerns  terminal  variables,  each  distinct  E-type  (voltage) 
and  I-type  (current)  variable  of  the  network  must  be  defined  by  an 
equation  in  some  element.   The  manner  in  which  equations  defining 
terminal  variable  behavior  are  associated  with  elements  depends  on  the 
meaning  of  the  elements — there  is  no  rigid  general  rule.   The  two  most 
common  fashions  of  defining  terminal  variable  behavior  are  described  in 
the  following  two  paragraphs. 

Functional  elements  which  have  distinct  input  and  output  lines 
typically  include  one  equation  for  each  terminal  variable  at  each  external 
'output'  terminal.   In  these  cases,  one  and  only  one  'output'  terminal 
will  be  connected  to  each  node.   The  voltage  summer  of  the  previous 
section  is  an  example  of  such  an  element. 

Elements  which  make  no  distinction  between  input  and  output 
terminals  typically  include  one  equation  for  each  E/I-set  pair  at  each 
external  terminal.   There  is  only  one  equation  for  each  pair  of  terminal 
variables  because  the  terminal  variables  of  a  network  are  not  usually 
distinct — i.e.,  connecting  two  terminals  essentially  equivalences  their 
terminal  variables  (with  a  difference  in  sign  for  I-set  variables) . 
Thus,  equations  defining  the  behavior  of  the  terminal  variables  of  one 
element  are  present — in  effect — in  connected  elements.   In  these  cases,  an 
element  with  M  unconnected  external  terminals,  each  having  P  pairs  of 
E/I-set  variables,  will  typically  include  MP  equations  defining  terminal 
variable  behavior.   In  elements  with  multiple  external  terminals  (M>1) 
there  is  typically  one  equation  for  each  I-set  variable.   This  equation 
relates  the  values  of  the  I-set  variable  at  all  of  the  external  terminals 
usually  by  summing  these  values  to  zero.   For  each  E/I-set  pair  the 
remaining  M-l  equations  relate  the  values  of  the  E-set  variable  at  the  M 
external  terminals. 

The  remainder  of  this  section  presents  four  examples  of  element 
definitions  which  illustrate  the  use  of  equations  to  define  terminal 
variable  behavior  in  the  fashion  described  in  the  preceding  paragraph. 
These  examples  come  from  the  areas  of  electrical,  mechanical,  fluid,  and 
structural  networks.   The  elements  to  be  modeled  are  a  capacitor,  a  spring, 
a  reservoir,  and  a  beam. 
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Capacitor 

A  graphical  representation  of  a  capacitor  and  the  MODEL  text  dialect 
statements  which  define  this  element  are  shown  in  Figure  3.6. 

]  2 

O 1  I O 


TYPE  ELECTRIC  E(V)  1(1) 

ELEMENT  CAPACITOR  C 
TERMINALS  1:2  ELECTRIC 
EXTERNALS  1:2 
EQUATIONS  I(l)+I(2)=0 

V(1)'-V(2)'=I(1)/C 


Figure  3.6.   Capacitor. 

The  capacitor  has  one  parameter,  C,  which  is  its  capacitance. 
Terminals  1  and  2  are  external  terminals  of  type  ELECTRIC  with  E-set 
consisting  of  V,  the  voltage,  and  I-set  consisting  of  I,  the  current. 
The  first  equation  states  that  any  applied  current  is  transmitted  through 
the  capacitor.   The  second  equation  relates  the  voltage  across  the  capacitor 
to  the  current  through  it  according  to  the  capacitor  equation 

V  =  1/C  /i  dt 
This  equation  has  been  differentiated  to  yield 

V  =  i/C 
We  have  expressed  this  equation  as  if  positive  current  enters  at  terminal 
1,  representing  the  voltage  across  the  capacitor  as  V(l)  -  V(2)  and  the 
current  through  the  capacitor  as  1(1).   This  yields  the  equation 
V(l)'  -  V(2)'  =  I(l)/C.   Since  1(1)  =  -1(2),  this  is  equivalent  to  the 
equation  V(2) '  -  V(l)'  =  I(2)/C,  which  is  the  natural  form  when  positive 
current  enters  at  terminal  2. 

The  capacitor  model  could  be  connected  to  any  similarly  modeled 
electrical  elements  such  as  other  capacitors,  resistors,  inductors, 
voltage  and  current  sources  and  sinks,  diodes,  transistors,  etc. 

Spring 

A  graphical  representation  of  a  spring  and  the  MODEL  text  dialect 
statements  which  define  this  element  are  shown  in  Figure  3.7. 
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TYPE  MECH  E(X)  1(F) 

ELEMENT  SPRING  K;L 
TERMINALS  1:2  MECH 
EXTERNALS  1:2 
EQUATIONS  F(l)+F(2)=0 

K*(X(2)-X(1)-L)=F(2) 


Figure  3.7.   Spring. 

The  spring  has  two  parameters,  K  and  L,  which  are  its  spring 
constant  and  its  undeformed  length,  respectively.   Terminals  1  and  2  are 
external  terminals  of  type  MECH  with  E-set  consisting  of  X,  the  displacement, 
and  I-set  consisting  of  F,  the  force.   The  first  equation  states  that 
applied  forces  are  transmitted  through  the  spring. 

The  second  equation  relates  the  deformation  of  the  spring  to  the 
force  exerted  by  the  spring  according  to  Hooke's  law,  KAX  =  F.   The  positive 
X  axis  is  assumed  to  be  in  the  direction  from  terminal  1  toward  terminal  2. 
Thus,  the  deformation  of  the  spring  is  expressed  as  X(2)  -  X(l)  -  L.   The 
associated  force  exerted  by  the  spring  is  F(2)  whose  positive  direction 
is  from  terminal  2  toward  terminal  1.   Hence  the  equation 

K*(X(2)  -  X(l)  -  L)  =  F(2) 

This  spring  model  could  be  connected  to  any  similarly  modeled 
mechanical  elements  such  as  other  springs,  fixed  and  movable  masses, 
forces,  etc. 

Reservoir 

A  graphical  representation  of  a  reservoir  and  the  MODEL  text 
dialect  statements  which  define  this  element  are  shown  in  Figure  3.8. 

The  reservoir  has  three  parameters,  AO,  Al ,  and  HI,  which  are 
the  area  of  the  reservoir's  surface,  the  cross-sectional  area  of  the 
outlet,  and  the  height  of  the  outlet,  respectively.   Local  variables  HO, 
PI,  and  VI  are  used  to  represent  the  height  of  the  reservoir's  surface, 
the  pressure  at  the  outlet,  and  the  velocity  of  the  fluid  through  the 
outlet.   The  outlet  is  represented  by  terminal  1.   This  is  an  external 
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terminal  of  type  FLUID  with  E-set  consisting  of  B,  the  sum  of  the  kinetic, 
potential,  and  intrinsic  energy  of  the  fluid,  and  I-set  consisting  of  FLOW, 
the  flow  rate  of  the  fluid. 


ZI  o 


TYPE  FLUID  E(B)  I (FLOW) 
GLOBALS  GAMMA;  G 

ELEMENT  RESERVOIR  A0;A1;H1 
LOCALS  H0;P1;V1 
TERMINALS  1  FLUID 
EXTERNALS  1 

EQUATIONS  HO'*AO-FLOW(1)=0 
V1=-FL0W(1)/A1 

B(l)=Pl/GAMMA+Vl**2/(2+G)*Hl 
B(1)-H0 

Figure  3.8.   Reservoir. 


The  first  equation  defines  the  rate  of  change  in  the  height  of 
the  reservoir's  surface,  HO',  in  terms  of  the  rate  at  which  fluid  flows 
out  of  the  reservoir  which  is  -FL0W(1)  by  convention.   The  second  equation 
defines  the  velocity  of  the  fluid  flow  through  terminal  1,  VI,  in  terms  of 
the  rate  of  flow.   The  last  two  equations  define  the  pressure,  PI,  and 
total  energy,  B(l),  of  the  fluid  at  terminal  1.   They  make  use  of  the 
Bernoulli  equations  of  fluid  mechanics  applied  to  a  steady  flow  situation. 
These  equations  state  that  the  quantity 

V2/2G  +  H  +  P/GAMMA 
has  the  same  value  at  any  point  along  a  flow  line.   The  variables  in  this 
quantity  are 

G      the  acceleration  due  to  gravity 

GAMMA   the  density  of  the  fluid 

V      the  velocity  of  the  fluid  at  the  point  in  question 

P      the  pressure  of  the  fluid  at  the  point  in  question 
(above  one  atmosphere) 

H      the  height  of  the  point  in  question 
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The  equation 

B(l)  =  PI/GAMMA  +  V1**2/(2*G)  +  HI 
relates  the  total  energy  at  terminal  1,  B(l),  to  the  fluid  pressure,  velocity, 
and  height  there.   The  equation 

B(l)  =  HO 
equivalences  the  values  of  the  Bernoulli  quantity  at  terminal  1  and  at  the 
surface,  where  the  pressure  is  one  atmosphere  and  the  velocity,  HO',  is  too 
small  to  affect  the  Bernoulli  quantity  appreciably. 

The  reservoir  model  could  be  connected  to  any  similarly  modeled 
fluid  elements  such  as  other  reservoirs,  pipes,  flow  sinks  and  sources,  etc. 

Beam 

A  graphical  representation  of  a  structural  beam  and  the  MODEL 
text  dialect  statements  which  define  this  element  are  shown  in  Figure  3.9. 
The  beam  parameters  and  terminal  variables  represent  the  following 

quantities: 

2 
E    Young's  modulus,  in  lbs/ft  .   This  depends  only  on 

the  material  of  the  beam; 

I    Moment  of  inertia  of  the  beam  about  the  axis  perpendicular 
to  the  plane  of  bending; 

A    Cross-sectional  area  of  the  beam; 

L    Length  of  the  beam; 

DX   Displacement  of  the  terminal  in  the  X  direction; 

DY   Displacement  of  the  terminal  in  the  Y  direction; 

DTH  Angular  rotation  of  the  terminal  in  the  XY  plane; 

PX   Force  applied  at  the  terminal  in  the  X  direction; 

PY   Force  applied  at  the  terminal  in  the  Y  direction; 

MXY  Moment  applied  at  the  terminal  in  the  XY  plane. 

The  equations  of  Figure  3.9  model  the  terminal  variables  of  the 
beam  in  a  static  situation  (see  [4]).   This  illustrates  the  use  of  MODEL 
to  solve  static  as  well  as  dynamic  systems.   Since  no  derivatives  or 
differential  equations  are  present  and  the  independent  variable  is  not 
used,  a  structural  network  modeled  in  this  fashion  will  be  solved  at 
only  one,  arbitrary  value  of  TIME. 

The  beam  model  could  be  connected  to  any  similarly  modeled 
structural  elements  such  as  other  beams,  loads,  and  immovable  masses.   To 
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represent  a  vertical  beam  it  is  necessary  to  replace  PX  and  DX  with  PY  and 
DY  in  the  equations  and  vice  versa  in  order  to  maintain  a  single 
coordinate  system. 
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\i  i  in  1 1  n  a  1 1 1 1 1  a  1 1 1 1  a  1 1 1  ii  1 1 1 1. 


o 


in  in  ii  1 1  a  i  mi  in  in  it  i  nuii 


The  positive  direction  conventions  for  the  terminal  variables  are 


PX(1) 


PY(1) 
Ol 


2o 


PX(2) 
PY(2) 


TYPE  STRUCT  E(DX;DY;DTH)  I(PX;PY;MXY) 

ELEMENT  BEAM  E;I;A;L 

TERMINALS  1:2  STRUCT 

EXTERNALS  1:2 

EQUATIONS  PX(1)=(E*A/L)*DX(1) 

PY(1)=(6*E*I/(L*L))*((2/L)*DY(1)-DTH(1)-DTH(2)) 

MXY(l)=(2*E*I/L)*((-3/L)*DY(l)+2*DTH(l)+DTH(2)) 

PX(2)=(E*A/L)*DX(2) 

PY(2)=(6*E*I/(L*L))*((2/L)*DY(2)-DTH(1)-DTH(2)) 

MXY(2)=(2*E*I/L)*((-3/L)*DY(2)+2*DTH(2)+DTH(l)) 


Figure  3.9.   Static,  prismatic  beam  in  two  dimensions. 


3. A. 6.   Logical  Switching  of  Equations 

MODEL  supports  the  logical  switching  of  equations  via  IF,  THEN, 
ELSE  IF,  and  ELSE  clauses  within  EQUATIONS  statements.   The  general  form 
of  a  conditional  equation  is 

IF  aond   THEN  eqn 
{ELSE  IF  aond   THEN  eqn}* 

ELSE  eqn 
Each  use  of  eqn   represents  any  MODEL  equation.   Each  use  of  aond   represents 
a  condition  such  as  X  <  Y  &  Y  >  Z.   The  relational  operators  <  (less  than) 
and  >  (greater  than)  can  be  used  to  define  threshold  relations  between 
arbitrary  scalar  expressions.   The  logical  operators  &  (and)  and    (or) 
can  be  used  to  define  arbitrary  conditions  consisting  of  logically  combined 
threshold  relations. 

The  logical  switching  of  equations  is  illustrated  by  the  following 
example  which  is  an  extension  of  the  capacitor  model  of  the  previous  section 
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This  model  is  an  idealized  air  capacitor  to  which  the  additional  parameters 
VMAX  and  RL  have  been  added.   VMAX  represents  the  maximum  voltage  across 
the  capacitor.   When  the  capacitor  voltage  reaches  VMAX,  the  air  between 
the  capacitor  plates  ionizes.   This  establishes  a  conductive  path  with 
resistance  RL  across  the  capacitor.   The  capacitor  will  then  draw  a  greater 
current  due  to  its  lower  impedance  in  the  ionized  state.   This  current 
may  eventually  drain  the  capacitor  voltage  below  VMAX  at  which  point  the 
capacitor  resumes  its  normal  operation. 

This  situation  can  be  modeled  by  replacing  the  capacitor  equation 
V(l)1  -  V(2)'  =  I(l)/C  with  the  conditional  equation 

IF  ABS(V(1)-V(2))  >  VMAX  THEN  V(l)  -  V(2)  =  I(1)*RL 

ELSE  V(l)*  -  V(2)'  =  I(l)/C 
Logical  switching  of  equations  is  also  useful  in  a  spring  model 
to  describe  the  nonlinear  operation  of  the  spring  when  a  threshold  value  of 
AX  is  exceeded.   In  this  case  we  might  represent  the  spring's  undeformed 
length  as  a  local  variable  whose  initial  value  is  specified  as  a  parameter, 
and  add  the  parameters  DELMAX  to  represent  the  threshold  AX,  and  C  to 
represent  the  modulus  of  stretching.   The  spring  could  then  be  modeled 
by  the  equations 

F(l)  +  F(2)  =  0 

K*(X(2)-X(1)-L)  =  F(2) 
IF  X(2)  -  X(l)  <  DELMAX  THEN  L1  =  0 
ELSE  L'  =  C*(X(2)'-X(1) ') 
The  conditional  equation  above  describes  an  idealized  hysteresis 
effect.   In  general,  an  idealized  hysteresis  loop  with  slope  S  such  as  the 
loop  shown  in  Figure  3.10  can  be  modeled  by  the  conditional  equation 
IF  X'  >  0  &  Y  <  S*(X-P1)  THEN  Y'  =  S*Xf 
ELSE  IF  X'  <  0  &  Y  >  S*(X-P2)  THEN  Y'  =  S*X' 
ELSE  Y'  =  0 
or  by  the  more  concise  conditional  equation 

IF  X'  >  0  &  Y  <  S*(X-P1)|X'  <  0  &  Y  >  S*(X-P2)  THEN  Y1  =  S*X' 
ELSE  Y'  =  0 


Figure  3.10.   Idealized  hysteresis  loop  with  slope  S, 


In  a  reservoir  model,  one  might  use  a  conditional  equation  to 
describe  the  situation  when  the  reservoir  is  drained.   For  example,  if 
fluid  never  enters  the  reservoir  through  terminal  1,  one  might  add  the 
conditional  equation 

IF  HO  <  HI  THEN  HO'  =  0 
ELSE  HO'  =  HO' 
The  ELSE  clause  is  needed  only  to  conform  to  the  syntax  of  a  conditional 
equation  since  it  obviously  has  no  effect  on  the  system  solution. 

A  conditional  structure  of  IF,  THEN,  and  ELSE  clauses  was 
chosen  over  the  provision  of  procedural  blocks,  and  conditional  branching 
statements  because  the  former  requires  no  familiarity  with  concepts  of 
procedural  control  and  branching.   It  is  this  author's  opinion  that  IF, 
THEN,  and  ELSE  clauses  are  more  natural  for  the  inexperienced  programmer 
than  are  procedural  branching  statements.   Although  a  conditional 
equation  is  a  procedural  sequence  in  which  ELSE  clauses  are  executed  only 
when  the  preceding  IF  clauses  are  'false',  it  is  natural  to  think  of  a 
conditional  equation  as  a  single  parallel  statement.   Within  this  framework 
users  with  no  procedural  programming  experience  can  define  models  which 
include  logical  switching  of  equations  in  a  quasi-parallel  fashion.   Any 
necessary  procedural  code  can  be  interfaced  to  the  model  in  the  form  of 
FORTRAN  subroutines. 

Presently  each  THEN  and  ELSE  clause  must  contain  a  single  equation, 
A  routine  extension  of  the  MODEL  language  would  allow  parallel  blocks  of 
equations  to  be  structured  in  these  clauses. 
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3.4.7.  Initial  Value  Assignment 

Initial  values  for  MODEL  variables,  parameters,  and  their 
derivatives  are  specified  via  the  INITIAL  statement.   In  the  text  dialect 
this  statement  has  the  general  form 

INITIAL  {var   =  eonst-eocp;}* 
In  DRAGON,  the  INITIAL  function  is  selected  and  the  remainder  of  the  statement 
is  typed  in.   Each  use  of  var   represents  a  variable,  parameter,  or  derivative 
of  the  element.   Each  use  of  oonst-exp   represents  any  expression  whose 
operands  are  constants,  parameters  of  the  highest  level  element  of  the  model, 
or  variables  or  parameters  which  are  equivalenced  to  one  of  these.   Initial 
values  may  be  scalar  or  higher-dimensioned  expressions.   They  may  be  passed 
as  parameters  to  an  element  allowing  different  initial  values  for  each 
invocation.   Parameterization  of  initial  values  in  the  highest  level  element 
of  a  model  allows  initial  values  to  be  specified  at  run  time. 

One  initial  value  may  be  assigned  for  each  variable/derivative 
pair  in  the  model.   After  the  initial  values  specified  by  the  user  are 
assigned,  the  numerical  software  will  compute  initial  values  for  uninitial- 
ized variables  and  derivatives  which  yield  a  steady  initial  state  of  the 
model.   Thus,  it  is  not  necessary  to  specify  an  initial  value  for  every 
variable/derivative  pair. 

Some  initial  values  are  typically  required  to  begin  the  simulation 
from  a  desired  system  state.   In  using  the  spring  and  reservoir  models  of 
section  3.4.5,  for  example,  one  might  want  to  specify  the  initial  displace- 
ments of  the  spring  endpoints  or  the  initial  height  of  the  reservoir's 
surface.   This  is  facilitated  by  passing  initial  values  as  element  parameters. 
For  example,  one  might  add  the  parameter  HINIT  and  the  statement 

INITIAL  HO  =  HINIT 
to  the  definition  of  the  reservoir  model.   This  would  allow  the  initial 
height  to  be  independently  specified  for  each  reservoir  used  in  a  fluid 
network. 

3.4.8.  Termination  Logic 

The  conditions  under  which  the  model  execution  is  to  be  terminated 
are  specified  by  means  of  the  STOP  clause  within  an  EQUATIONS  statement. 
The  form  of  this  clause  is  IF  aond   STOP  {=n)   where  cond   represents  any 
condition  as  described  in  section  3.4.6  and  n   represents  an  optional 
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constant  termination  code  specified  by  the  user.   An  ELSE  clause  is  not 
allowed  after  the  STOP  clause. 

Every  model  must  include  at  least  one  termination  condition. 
A  termination  condition  might  be  a  simple  threshold  on  the  independent 
variable ,  i.e., 

IF  TIME  >  10  THEN  STOP 
or  it  might  be  a  logical  combination  of  thresholds  in  variables  and 
parameters  of  the  element  which  represents  either  normal  or  abnormal 
termination.   For  example,  the  statement  IF  V(l)  >  VMAX  THEN  STOP  =  1 
might  be  included  in  an  element  which  models  a  fuse  to  terminate  the 
simulation  if  the  fuse  blows.   If  this  condition  arises  during  the 
simulation,  execution  of  the  model  will  stop.   The  termination  code  '1' 
will  be  printed  and  also  assigned  to  the  system  variable  ISTOP.   The 
printed  termination  code  communicates  the  termination  condition  to  the  user 
while  the  system  variable  ISTOP  allows  the  FORTRAN  program  which  controls 
the  model  execution  to  alter  the  control  sequence  according  to  the 
termination  condition.   If  no  termination  code  is  specified,  ISTOP  will 
have  the  value  0 . 

A  termination  code  may  be  a  parameter  to  the  element  in  which 
the  STOP  clause  is  specified  provided  that  this  parameter  is  always 
replaced  by  a  constant  when  the  element  is  invoked.   This  allows  a 
different  termination  code  to  be  associated  with  each  instance  (that  is, 
each  copy)  of  the  element  invoked  in  the  model. 

Parameterization  of  termination  conditions  allows  these  conditions 
to  be  controlled  by  the  invoking  element.   Parameterization  of  termination 
conditions  in  the  highest  level  element  of  the  model  allows  these  conditions 
to  be  controlled  at  run  time  through  the  assignment  of  values  for  the 
parameters  of  the  highest  level  element. 

Simple  thresholds  on  the  independent  variable  can  also  be 
specified  in  the  run-control  language  through  the  system  parameter  TSTOP. 
For  example,  the  assignment  TSTOP  =  10  in  the  run-control  language  has 
the  same  effect  as  the  clause 

IF  TIME  >  10  STOP 
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3.4.9.   Output 

The  variables  of  an  element  whose  histories  are  to  be  recorded  for 
output  are  specified  via  the  OUTPUT  statement.   In  the  text  dialect,  this 
statement  has  the  general  form 

OUTPUT  {var;}* 
where  var   represents  a  variable  name.   In  DRAGON,  the  output  variables  are 
specified  by  selecting  the  OUTPUT  function  and  typing  in  the  remainder  of 
the  statement. 

The  output  variables  are  recorded  at  regular  intervals  during  the 
integration  of  the  model.   The  frequency  at  which  values  are  recorded — or 
the  communication  interval — is  specified  through  the  COMINT  system  control 
parameter.   The  interval  in  the  independent  variable  between  recording 

operations  is  simply  the  value  assigned  to  the  COMINT  parameter.   The  default 

_2 
value  for  COMINT  is  10   .   Non-default  values  are  specified  in  the  run-control 

program,  which  is  discussed  in  section  3.6. 

Solution  histories  can  be  recorded  on  any  logical  unit  number 
between  6  and  90.   Unit  6,  the  standard  line  printer  unit,  is  used  for 
default.   A  different  logical  unit  can  be  specified  by  means  of  the  UNIT 
statement,  which  has  the  general  form 

UNIT  n 
where  n   is  any  integer  between  6  and  90.   In  the  text  dialect,  this  statement 
precedes  the  first  element  definition  of  the  model.   In  the  DRAGON  dialect, 
the  UNIT  statement  is  entered  in  the  header  block. 

A  title  for  the  solution  history  can  be  specified  via  the  TITLE 
statement,  which  has  the  general  form 

TITLE  title-string 
where  title-string   is  any  character  string.   Like  the  UNIT  statement,  the 
TITLE  statement  precedes  the  first  element  definition  of  the  model  in  the 
text  dialect  and  is  entered  in  the  header  block  in  the  DRAGON  dialect. 

The  user  is  free  to  examine  and  alter  the  FORTRAN  subroutine  which 
is  used  to  record  system  states  so  great  flexibility  in  data  recording  is 
available  at  the  FORTRAN  level.   Present  plans  call  for  MODEL  itself  to  be 
extended  to  provide  flexible  operators  for  recording,  filing,  and  restoring 
solution  states  at  a  higher  level.   A  sophisticated  plot  package  [5]  will 
also  be  interfaced. 


101 


The  FORTRAN  subroutine  RECORD,  which  performs  the  solution  recording, 
is  shown  for  a  sample  model  in  Appendix  B.   RECORD  has  four  arguments,  INIT, 
IUNIT,  N,  and  A.   The  values  of  the  output  variables  are  passed  to  RECORD  in 
the  vector  A  whose  length  is  N.   IUNIT  is  the  logical  unit  number  specified 
in  the  model  or  the  default  unit,  six.   INIT  is  a  flag  which  is  zero  when 
the  initial  state  is  recorded  and  one  after  the  integration  begins.   When 
the  initial  state  is  recorded,  the  output  title  and  labels  (which  are  the 
names  by  which  the  output  variables  are  known  in  the  model)  are  recorded  as 
a  header  for  the  solution  history.   The  labels  indicate  the  order  in  which 
the  values  of  the  output  variables  appear  in  the  array  A.   Since  these  labels 
appear  clearly  within  subroutine  RECORD,  it  is  quite  easy  for  the  user 
familiar  with  FORTRAN  to  alter  this  subroutine  to  perform  more  sophisticated 
recording  and  output  operations. 

3.5 .   Function  Subprograms,  Subroutines,  and  Table  Functions 

The  user  can  define  FORTRAN  function  and  subroutine  subprograms 
to  evaluate  special  functions  needed  in  equations,  conditions,  and  initial 
and  parameter  values.   Scalar  functions  can  be  defined  as  function 
subprograms  while  nonscalar  functions  are  defined  as  subroutines.   Within 
MODEL  equations  both  types  of  subprograms  are  referenced  as  functions. 
When  a  subroutine  is  defined,  the  vector  or  array  result  must  be  the  last 
dummy  argument  of  the  definition.   In  referencing  the  subroutine  in  MODEL 
equations,  this  argument  is  omitted  as  is  the  CALL  statement.   MODEL 
automatically  generates  the  CALL  statement  inserting  a  MODEL-generated 
address  for  the  result.   The  result  is  then  automatically  inserted  into 
the  equation  in  the  place  of  the  subroutine  name.   This  permits  the 
convenience  of  function-type  referencing  for  both  scalar  and  nonscalar 
functions — subprogram  references  may  be  freely  nested  and  embedded  in 
expressions.   No  other  language  allows  subroutine  references  to  be 
nested  or  embedded  in  expressions. 

Each  FORTRAN  subprogram  used  in  a  model  must  be  defined  by  a 
FORTRAN  source  or  object  subprogram  and  its  syntax  must  be  defined  by  a 
MODEL  subprogram  syntax  statement.   The  MODEL  subprogram  syntax  statement 
permits  MODEL  to  analyze  the  syntax  of  subprogram  references  and,  in  the 
case  of  subroutines,  to  perform  the  automatic  insertion  of  the  nonscalar 
result  into  the  expression  which  references  the  subroutine.   The  FORTRAN 
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subprogram  performs  the  function  evaluation  during  the  model  execution. 
It  may  be  defined  by  passing  the  FORTRAN  source  code  through  MODEL,  or 
by  submitting  it  to  the  FORTRAN  step  or  compiling  it  separately  and  including 
the  object  code  in  the  link-load  step.   The  latter  two  alternatives 
allow  FORTRAN  subprograms  to  be  altered  without  recompiling  the  model. 
Standard  link-editor  commands  at  most  installations  permit  this  approach 
to  be  used  to  replace  subprograms  whose  source  code  was  passed  through  MODEL. 
The  MODEL  subprogram  syntax  statements  have  the  general  forms 

FUNCTION  funo-name  n-args 

SUBROUTINE  funo-name  n-args    {RVECTOR  {d-}| 

CV ECTOR  {d  }| 
ARRAY  {d  d  }} 
where  funo-name   represents  the  name  of  the  subprogram  and  n-args   represents 
the  number  of  arguments  used  in  referencing  the  subprogram  in  MODEL  equations, 
Thus,  for  a  subroutine  which  is  defined  with  M  dummy  arguments  (the  last  of 
which  is  its  result),  n-args   should  be  M-l  since  the  last  argument  is 
omitted  in  subroutine  references  within  MODEL  equations.   The  optional 
RVECTOR,  CVECTOR,  or  ARRAY  clause  is  used  to  specify  the  extent  of  the 
nonscalar  result.   The  RVECTOR  clause  specifies  that  the  result  is  a  row 
vector,  that  is,  1  x  n.   The  CVECTOR  clause  specifies  a  column  vector, 
n  x  1.   The  ARRAY  clause  specifies  an  array,  n  x  m.   If  the  result  always 
has  the  same  extent,  the  extent  can  be  specified  by  the  optional  integers 
d     and  d*.      If  the  extent  of  the  result  depends  on  the  actual  arguments 
used  in  referencing  the  subroutine,  no  extents  are  specified  in  the 
subprogram  syntax  statement.   In  this  case,  the  extent  of  the  result  must 
be  defined  as  the  first  dummy  argument  (for  vectors)  or  as  the  first  two 
dummy  arguments  (for  arrays)  of  the  subroutine.   This  allows  a  single 
subroutine  to  be  used  for  an  operation  such  as  taking  the  transpose  of  a 
matrix,  regardless  of  the  extent  of  the  array.   Only  integer  constants 
may  replace  these  dummy  arguments  when  the  subroutine  is  referenced  in 
MODEL  equations.   If  the  SUBROUTINE  statement  includes  no  RVECTOR, 
CVECTOR,  or  ARRAY  clause,  the  result  is  assumed  to  be  an  array  whose 
extent  is  specified  in  this  fashion. 

In  the  text  dialect,  subprogram  syntax  statements  precede  the 
first  ELEMENT  statement  of  the  input  file.   In  DRAGON,  subprogram  syntax 
statements  are  entered  by  selecting  the  HEADER  function  and  typing  in  the 
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statements.   This  enters  the  syntax  statements  in  the  header  block  of  the 
element  under  construction.   When  the  MODEL  compiler  is  invoked  from 
DRAGON,  the  statements  in  the  header  block  of  the  highest  level  element  of 
the  model  are  included  in  the  input  file  passed  to  the  compiler. 

In  the  text  dialect,  any  FORTRAN  source  codes  which  are  passed 
through  MODEL  must  be  placed  in  a  different  part  of  the  input  file  than 
the  model  definition — see  Appendix  A.   In  DRAGON,  a  FORTRAN  source  code  is 
added  to  the  FORTRAN  menu  by  selecting  the  FORTRAN  function  and  typing  in 
the  source  code.   When  the  MODEL  compiler  is  invoked  from  DRAGON,  the  entire 
FORTRAN  menu  is  included  in  the  input  file  passed  to  the  compiler. 

Any  legal  FORTRAN  subprograms  which  do  not  use  blank  common  are 
allowed.   The  MODEL  compiler  allows  at  most  24  FORTRAN  subprograms  to  be 
defined  for  use  in  MODEL  equations.   A  MODEL  subprogram  syntax  statement 
must  be  provided  for  each  of  these.   A  syntax  statement  is  not  required 
for  FORTRAN  subprograms  which  are  called  in  the  run-control  program  or  in 
other  subprograms  but  are  not  referenced  in  MODEL  equations.   Any  number 
of  these  subprograms  can  be  accommodated. 

The  user-supplied  FORTRAN  code  and  the  FORTRAN  code  produced  by 
MODEL  can  be  listed  by  including  a  FLIST  statement  either  before  the  first 
element  definition  of  a  text  dialect  model  or  in  the  header  block  of  a 
DRAGON  dialect  model.   This  is  useful  for  diagnostic  purposes  and  for  the 
purpose  of  altering  any  of  these  FORTRAN  codes  without  repeating  the 
MODEL  step. 

MODEL  allows  empirical  data  functions  of  one  variable  to  be 
defined  in  tabular  fashion.   In  the  text  dialect,  this  is  done  through 
the  TABLE  statement.   TABLE  statements  must  follow  the  last  element 
definition  of  the  input  file — see  Appendix  A.   The  TABLE  statement  has 
the  general  form 
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TABLE  tabno 


-2  -2 


x  t 
— n  — n 

tabno   represents  a  unique  integer  by  which  the  specific  table  function  is 
identified.   The  x_.  represent  the  points  at  which  the  function  values,  _t .  , 
are  known  empirically.   The  x.  must  appear  in  increasing  order. 

In  DRAGON,  table  functions  are  defined  in  the  same  way  as  FORTRAN 
subprograms.   Selection  of  the  FORTRAN  function  allows  the  user  to  type  the 
name  by  which  the  table  function  will  be  known  in  the  library,  followed  by 
the  TABLE  statement.   The  table  function  is  then  added  to  the  FORTRAN  menu 
and  automatically  passed  to  the  MODEL  compiler  when  it  is  invoked. 

Any  number  of  table  functions  may  be  defined.   They  may  be 
referenced  in  the  equations  of  any  element  in  the  form  TABLE {tabno,   org) 
where  tabno   represents  the  integer  which  identifies  the  specific  table 
function  and  avq   represents  the  point  at  which  the  table  function  is  to  be 
interpolated  (or  extrapolated) . 

3.6.   Run-Control 

The  execution  of  a  simulation  model  is  controlled  by  a  FORTRAN 
run-control  program  which  can  utilize  system  control  parameters,  system 
subroutines  which  invoke  the  model  execution,  any  any  user-supplied  FORTRAN 
subroutines.   The  parameters  and  variables  of  the  highest  level  element 
can  be  referenced  as  FORTRAN  variables,  permitting  parameter  adjustment  and 
response  testing  procedures  which  are  as  simple  or  as  sophisticated  as  the 
user's  understanding  of  FORTRAN  permits.   When  the  run-control  program  is 
submitted  to  MODEL  with  the  model  definition,  MODEL  automatically  inserts 
declarations  for  these  FORTRAN  variables,  relieving  the  user  of  this  task. 
These  variables  reside  in  COMMON  storage  sc  the  user  need  not  pass  them 
as  arguments  to  the  model  execution.   MODEL  also  automatically  inserts 
EQUIVALENCE  statements  which  map  the  names  by  which  these  parameters  and 
variables  are  known  in  the  model  into  members  of  the  FORTRAN  arrays  where 
variables  are  maintained  during  the  model  execution.  This  permits  references 
at  the  problem  description  level  in  the  run-control  program. 
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The  run-control  program  need  not  be  submitted  to  MODEL,  however. 
When  desirable,  the  run-control  program  can  be  submitted  at  the  FORTRAN  or 
object  step  rather  than  the  MODEL  step.   In  these  cases,  a  printed 
diotioncwy   of  the  parameters  and  variables  of  the  model  can  be  obtained 
by  including  a  MAP  statement  before  the  first  element  definition  (text 
dialect)  or  in  the  header  block  (DRAGON  dialect)  of  the  model.   This 
dictionary  lists,  element-by-element,  the  problem-level  names  and 
corresponding  FORTRAN  array  members  for  each  variable  and  parameter  of 
the  model.   The  dictionary  allows  the  user  to  insert  appropriate 
EQUIVALENCE  statements  or  to  reference  model  variables  directly  as  members 
of  the  FORTRAN  arrays.   The  dictionary  for  a  sample  model  is  shown  in 
Appendix  B. 

When  the  run-control  program  is  not  submitted  to  MODEL,  declarations 
and  COMMON  statements  for  the  FORTRAN  arrays  in  which  variables  are 
maintained  must  be  inserted  by  the  user.   These  can  be  copied  exactly  as 
they  appear  in  the  default  run-control  program  produced  by  MODEL.   The 
default  run-control  program  can  be  printed  for  this  purpose  by  including 
an  FLIST  statement  before  the  first  element  definition  of  the  model. 
Appendix  B  shows  the  default  run-control  program  for  a  sample  model. 

3.6.1.   Parameter  Assignments 

Parameter  values  can  be  assigned  or  read  by  any  FORTRAN  procedure 
prior  to  and  between  invocations  of  the  model.   Parameter  assignments  are 
by  exception  only.   Once  assigned  a  value  a  parameter  will  keep  that  value 
until  reassigned.   This  applies  to  the  parameters  of  the  highest  level 
element  and  to  the  system  control  parameters  whose  names  and  meanings  are 
shown  in  Figure  3.11.   Default  assignments  for  the  system  control  parameters 
are  automatically  included  by  MODEL  in  default  run-control  programs  and  in 
non-default  run-control  programs  submitted  to  MODEL  (see  Appendix  B) .   When 
the  run-control  program  is  not  submitted  to  MODEL,  the  values  of  all  system 
control  parameters  must  be  assigned  by  user-supplied  code. 
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parameter 
TSTART 

TSTOP 

HMIN 
HMAX 
EPS 

DEL 

ISTOP 
COMINT 


meaning 

initial  value  of 
independent  variable 
(nominally  time) 

terminal  value  of  time 

minimum  time  step 

maximum  time  step 

maximum  relative  error 
for  each  time  step 

maximum  relative  error  in 
system  initialization 

termination  code 

frequency  of  solution 
recording 


default  value 


10 


10 


-2 


10 


-5 


10 


-5 


10 


Figure  3.11.   MODEL  system  control  parameters 


3.6.2.   Model  Invocation  and  Response  Testing 

Two  system  subroutines,  RUN  and  CONTIN,  are  provided  for 
invoking  the  model  execution.   The  difference  between  these  subroutines 
is  that  RUN  establishes  an  initial  state  for  all  variables  before 
beginning  the  integration  while  CONTIN  proceeds  from  an  established 
state.   Execution  of  CALL  RUN  causes  the  independent  variable  to  assume 
its  initial  value  (TSTART)  and  the  initial  values  specified  in  INITIAL 
statements  in  the  model  to  be  assigned, after  which  the  values  of  the  non- 
initialized  variables  are  adjusted  to  attain  a  steady  initial  state  of  the 
model.   On  the  other  hand,  CALL  CONTIN  causes  no  such  state  initialization 
prior  to  the  integration.   Integration  proceeds  from  the  last  terminal  state 
of  the  model  or  from  some  state  which  was  previously  recorded  and  restored 
by  user-supplied  code.   The  termination  prameter(s)  must,  of  course,  be 
altered  before  continuing  from  a  previous  terminal  state.   Otherwise,  CALL 
CONTIN  will  cause  immediate  termination  of  the  model  execution. 

The  sequence  of  calls  to  RUN  and  CONTIN  in  a  programmed  study 
is  controlled  by  the  FORTRAN  code  of  the  run-control  program.   Any  FORTRAN 
procedures  can  be  used  to  test  system  responses  (i.e.,  variable  values), 
alter  parameter  values,  and  determine  the  control  sequence  between  runs. 
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The  integer  variable  ISTOP,  which  indicates  the  condition  which  caused 
termination,  is  particularly  useful  for  the  latter  purpose. 

The  FORTRAN  run-control  used  by  MODEL  allows  great  flexibility 
for  sophisticated  studies  while  requiring  very  little  sophistication  for 
simple  problems.  Non-parameterized  models  can  make  use  of  default  run- 
control  (CALL  RUN).   A  non-default  run-control  program  may  be  as  simple 
as  (for  example) 

Pl=5 

P2=3.9 

CALL  RUN 
or  as  complex  as  procedures  for  parameter  optimization.   Use  of  the 
dictionary  allows  the  FORTRAN  run-control  program  to  be  submitted  after 
the  MODEL  step,  and  standard  link  editor  and  loader  options  permit  any 
of  the  FORTRAN  programs  produced  by  MAP  to  be  altered  without  recompiling 
the  model. 

Only  the  parameters  and  variables  of  the  highest-level  element 
can  be  referenced  at  the  problem-description  level  in  the  run-control 
program.   Lower-level  elements  may  be  invoked  many  times  in  a  model.   Thus, 
the  names  of  their  variables  and  parameters  may  not  be  unique  within  the 
model.   The  use  of  global  variables  permits  a  variable  within  a  lower- 
level  element  to  be  equivalenced  to  a  global  variable  of  the  highest 
level  element  which  can  be  referenced  at  the  problem-description  level. 
Alternatively,  the  use  of  the  dictionary  allows  the  user  to  reference  the 
FORTRAN  array  member  which  represents  any  variable  directly. 

3.7.   Diagnostics 

MODEL  provides  extensive  diagnostics  concerning  errors  and  possible 
errors  in  the  model  definition.   MODEL  reports  all  errors  in  the  model 
definition  rather  than  stopping  the  model  analysis  after  some  fixed  number 
of  errors  have  been  found.   Highlights  of  this  error  checking  include  a 
complete  source  language  equation  syntax  analysis  and  a  complete  analysis 
of  terminal  connections.   MODEL  attempts  only  the  most  trivial  error 
correction  such  as  the  truncation  of  identifiers  whose  names  are  longer 
than  eight  characters.   More  sophisticated  error  correction  is  not  attempted 
because  the  MODEL-to-FORTRAN  step  is  much  less  expensive  than  the  FORTRAN-to- 
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object  and  model  execution  steps  which  would  be  useless  if  MODEL  made  a 
wrong  correcting  assumption.   The  numerical  software  produces  diagnostics 
for  such  computational  difficulties  as  the  inability  to  find  a  steady 
initial  state,  the  inability  to  achieve  the  prescribed  error  tolerance 
within  the  allowable  range  of  step  sizes,  and  underflow  or  overflow 
resulting  from  the  inversion  of  an  ill-conditioned  matrix. 

The  diagnostics  produced  by  MODEL  are  classified  as  either  error 
messages  or  warning  messages.   Error  messages  describe  situations  which 
are  certain  errors  such  as  an  equation  with  a  missing  operator  or  the 
connection  of  two  terminals  of  different  types.   Warning  messages  describe 
trivial  errors  which  are  corrected  by  MODEL  such  as  a  variable  name  which  is 

longer  than  eight  characters,  and  situations  which  may  or  may  not  be  actual 

2 
errors  such  as  an  unequal  number  of  equations  and  variables. 

A  MODEL  program  is  terminated  after  the  model  compilation  if 
any  error  messages  are  produced.   Since  warning  messages  may  or  may  not 
signal  actual  errors,  two  options  are  available  in  response  to  these 
messages.   By  default  the  execution  of  the  model  will  be  attempted  if  only 
warning  messages  are  produced  by  the  compilation.   Alternatively,  the  user 
can  cause  the  execution  to  be  aborted  in  response  to  warning  messages  by 
including  an  ABORT  statement  either  before  the  first  element  definition  of 
the  model  (text  dialect)  or  in  the  header  block  (DRAGON  dialect). 

Diagnostics  may  be  produced  at  three  distinct  points  in  the 
analysis  performed  by  MODEL.   During  the  input  phase   of  model  analysis,  all 
syntax  errors  except  those  in  equations  and  initial  values  are  reported. 
These  messages  appear  after  the  source  line  which  is  in  error  and  the 
position  within  the  line  at  which  the  error  was  detected  is  indicated  by 
the  cursor  character  @.   Each  specific  error  in  an  element  definition 
detected  during  the  input  phase  is  reported  only  once  regardless  of  the 
number  of  times  that  element  is  invoked.   Thus,  these  errors  do  not  cause 
identical  messages  to  be  repeated  for  each  instance  of  an  element  in  the  model. 

During  the  expansion  phase   of  model  analysis,  each  element  instance 
invoked  in  the  model  is  expanded  into  a  set  of  equations.   The  equation  and 
initial  value  syntax  analysis  and  connection  analysis  are  performed  during 
this  phase.   Error  and  warning  messages  produced  during  this  phase  are 
specific  to  a  particular  element  instance.   Thus,  some  such  messages  may 
be  repeated  for  each  instance  of  a  given  element.   This  is  necessary  because 
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certain  potential  errors  concerning  equations  and  connections  depend  on  the 
context  of  the  instance  (i.e.,  the  global  variables  of  higher-level  elements 
and  the  types  of  externally  connected  terminals) .   Diagnostic  messages 
produced  during  the  expansion  phase  are  accompanied  by  the  element  name, 
qualified  by  the  names  of  its  ancestors  in  the  element  invocation  tree. 
These  messages  are  also  accompanied  by  a  line  of  text  which  clearly  identifies 
the  cause  of  the  error  such  as  the  equation  in  error  and  the  position  within 
the  equation  at  which  the  error  was  detected. 

During  the  output   phase  of  the  model  analysis,  the  expanded  set 
of  equations  which  represents  the  model  is  translated  from  an  internal 
representation  to  a  set  of  FORTRAN  subroutines.   Error  and  warning  messages 
produced  during  this  phase  concern  the  set  of  equations  of  the  model  as  a 
whole  and  are  not  specific  to  any  particular  element  or  instance.   These 
messages  are  accompanied  by  a  line  of  text  which  clarifies  the  cause  of 
the  error  or  possible  error  such  as  the  number  of  variables  and  the  number 
of  equations  if  these  are  different. 

The  format  of  MODEL  error  and  warning  messages  is  shown  in 
Figure  3.12.   Figure  3.12a  shows  a  generalized  diagnostic  message.   The 
first  line  indicates  the  source  line  cursor  position  and  is  used  only  in 
messages  produced  during  the  input  phase.   The  second  line  gives  the  element 
name  and  message  number.   Messages  produced  during  the  input  and  output 
phases  will  indicate  INPUT  and  OUTPUT,  respectively,  as  the  element  name. 
Messages  produced  during  the  expansion  phase  will  indicate  the  name  of  the 
element  in  error,  qualified  by  the  names  of  its  ancestors  in  the  element 
invocation  tree  to  identify  the  particular  element  instance.   The  message 
number  is  included  to  aid  the  user  in  looking  up  the  message  in  Appendix  A 
of  the  user's  manual  [3].   The  third  line  of  the  message  describes  the 
particular  error  which  was  detected.   Appendix  D  lists  these  error 
descriptions  along  with  the  associated  error  numbers.   The  fourth  line  of 
the  message  identifies  the  cause  of  the  error,  for  example,  by  listing  the 
equation  in  error  and  the  position  at  which  the  error  was  detected.   The 
fourth  line  is  not  necessary  for  messages  produced  during  the  input  phase. 
Thus,  all  messages  consist  of  three  lines. 

Figures  3.12b,  c  and  d  are  sample  messages  which  might  be 
produced  by  MODEL.  Figure  3.12b  is  the  warning  message  caused  by  a  terminal 
type  name  which  is  longer  than  eight  characters.   Figure  3.12c  is  the  error 
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message  caused  by  an  equation  which  has  a  missing  operator.   Figure  3.12d  is 
the  warning  message  caused  by  a  difference  in  the  number  of  equations  and 
the  number  of  variables  in  the  model. 


{@  indicating  source   line  cursor  position} 
IN  ELEMENT  name   ERROR  run 
description  of  error 
{identification  of  cause  of  error) 

Figure  3.12a 


(source  line)  TYPE  STRUCTURAL  @  E(DX;DY;DZ)  I(FX;FY;FZ) 
IN  ELEMENT  INPUT  WARNING  13 
TERMINAL  TYPE  NAME  SHORTENED  TO  8  CHARACTERS 

Figure  3.12b 


IN  ELEMENT  RESIST0R(2) .AMP. RADIO  ERROR  43 
EQUATION  IGNORED.   OPERATOR  MISSING  BEFORE  @ 
V(2)  -  V(l)  =  1(1)  @  R 

Figure  3.12c 


IN  ELEMENT  OUTPUT  WARNING  7 

SYSTEM  MAY  BE  SINGULAR.   NUMBER  OF  EQUATIONS  _,  =  NUMBER  OF  VARIABLES 

NUMBER  OF  EQUATIONS:   7,  NUMBER  OF  VARIABLES:   6 

Figure  3.12d 
Figure  3.12.   Format  of  MODEL  error  and  warning  messages. 


Ill 


NOTES 


Keywords  and  delimiters  appear  in  normal  type  and  must  appear  in  the 
same  fashion  in  specific  statements.   Italics  indicate  tokens  to  be 
supplied  by  the  user.   Braces  are  used  to  enclose  optional  phrases. 
The  asterisk  is  used  to  indicate  phrases  which  may  be  repeated  any 
number  of  times.   The  semicolon  is  used  as  the  delimiter  for  sequences 
of  phrases.   It  is  not  necessary  to  include  a  semicolon  after  the 
final  phrase  of  any  sequence. 


Analysis  of  electrical  and  structural  networks  frequently  leads  to  one 
or  more  redundant  node  equations  and  one  or  more  'floating'  variables. 
For  example,  the  simple  electrical  circuit  below  involves  four  voltages 
and  four  currents — one  voltage/current  pair  at  each  designated  terminal. 
There  are  eight  equations  present  of  which  the  first  four  below  come 
from  the  definitions  of  the  battery  and  resistor  elements  and  the 
remaining  four  come  from  the  two  terminal  connections. 

1.  V(1)=V(0)+1.5 

2.  I(0)+I(1)=0 

3.  V(3)=V(2)-I(2)*R 

4.  I(2)+I(3)=0 

5.  V(1)=V(2) 

6.  I(l)+I(2)=0 

7.  V(0)=V(3) 

8.  I(0)+I(3)=0 


However,  this  system  of  eight  equations  in  eight  variables  can  be 
simplified  by  eliminating  the  voltages  V(l)  and  V(2)  with  equations 
5  and  7  and  eliminating  the  currents  1(1),  1(2),  and  1(3)  with  equations 
2,  6  and  4.   This  simplification  yields  the  system 

9.  V(1)=V(0)+1.5 

10.  V(0)=V(1)-I(0)*R 

in  which  one  of  the  voltages  is  free  to  'float',  and  the  redundant 
node  equation 

8.   I(0)+I(3)=0 


which  is  implied  by  equations  2,  6,  and  4.   MAP  will  automatically 
perform  simplifications  like  those  above  and  will  also  recognize 
and  remove  redundant  equations  such  as  equation  8.   Thus,  MAP  would 
reduce  this  trivial  network  to  a  system  of  two  equations  (9  and  10) 
in  three  variables  (V(l),  V(0),  and  1(0)).   However,  this  does  not 
mean  that  the  network  model  is  in  error.   The  numerical  software  will 
simply  fix  one  of  the  voltages  at  zero,  effectively  reducing  the 
network  to  a  system  of  two  equations  in  two  variables. 
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It  is  worth  noting  that  if  V(0)  is  fixed  in  the  model  (say  at  zero), 
MAP  will  reduce  this  network  to  two  assignment  statements  to  the  effect 

V(l)=1.5 

I(0)  =  (V(1)-V(0))/R 

which  need  only  be  executed  once. 
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CONCLUSIONS 


Many  of  the  goals  presented  in  the  previous  chapters  have  been 
accomplished  in  the  present  implementation  of  MODEL,  but  some  desirable 
features  remain  to  be  achieved.   In  section  4.1  we  summarize  the  present 
implementation  in  terms  of  our  language  development  goals  and  the  extent 
to  which  they  have  been  realized.   Section  4.2  focuses  on  desirable 
features  which  have  yet  to  be  implemented  and  presents  some  possible 
approaches.   This  section  also  considers  the  manner  in  which  certain 
language  extensions  are  facilitated  or  restricted  by  the  present  implement at ior 

4.1.   Present  Implementation  of  MODEL 

The  primary  short  range  goal  in  the  development  of  MODEL  was  to 
produce  a  widely  applicable  and  easy-to-use  language  for  continuous 
network  simulation.   Secondary  short  range  goals  were  to  support  hierarchical 
models  and  different  levels  of  problem  and  user  sophistication  conveniently, 
to  allow  a  large  measure  of  portability,  and  to  permit  flexibility  in  the 
modeling  and  integration  environments.   These  goals  have  been  realized  to  a 
large  extent  in  the  present  implementation  of  MODEL. 

MODEL'S  ability  to  handle  generalized  connective  properties  and 
to  solve  any  user-written  equations  make  it  the  most  widely  applicable 
network  simulation  language  presently  available.   MODEL  makes  the  simulation 
of  network  models  from  a  great  many  disciplines  possible  within  a  single 
framework,  and  the  ability  to  define  and  employ  different  terminal  types 
allows  interdisciplinary  models  to  be  handled  directly.   Topological  modeling 
features,  a  free  text  format,  and  the  implicit  formulation  of  equations  make 
MODEL  very  easy  to  use.   The  local  implementation  also  provides  the  great 
convenience  of  graphical  modeling  and  library  support.   The  portable  dialect 
can  be  interfaced  easily  to  library  support  software  and  in  such  a  configura- 
tion would  be  as  convenient  as  any  existing  nongraphical  network  languages. 
Furthermore,  the  implicit  formulation  of  equations  makes  MODEL  more 
convenient  than  existing  equation-oriented  languages  for  most  non-network 
applications. 

The  structure  of  the  MODEL  language  was  designed  to  allow  the 
obvious  advantages  of  hierarchical  development  and  modular  design  within 
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simulation  models.   Elements  (i.e.,  modules)  may  be  nested  to  any  depth 
and  may  employ  flexible  variable  scoping  features.   The  language  makes 
no  distinction  between  elements  which  are  used  at  the  highest  level 
(e.g.,  a  radio  model)  and  those  which  are  used  at  lower  levels  (e.g., 
an  amplifier).   Thus,  any  element  can  be  added  easily  to  the  element 
library  for  later  use  as  a  subelement  and  lower  level  elements  of  a 
hierarchical  model  can  be  adapted  easily  for  independent  compilation  and 
simulation.   The  invocation  of  a  subelement  requires  only  the  specification 
of  the  parameters  and  external  connections  to  be  used  for  the  subelement 
instance.   Thus,  changes  in  the  definition  of  a  lower  level  element  which 
do  not  alter  the  number  or  type  of  its  parameters  and  external  connections 
require  no  corresponding  changes  in  the  definitions  of  higher  level 
elements.   These  features  allow  subsystem  models  to  be  refined  and  verified 
independently  in  the  development  of  a  hierarchical  model. 

MODEL  is  designed  to  provide  convenient  support  for  both  the 
sophisticated  user  with  a  complex  problem  and  the  novice  user  with  a  simple 
problem.   The  experienced  simulation  user-programmer  will  find  it  relatively 
easy  to  define  behaviors  at  the  equation  level  and  construct  new  elements 
representing  complicated  subsystems.   FORTRAN  procedures  of  arbitrary 
complexity  can  be  interfaced  to  the  model  to  evaluate  special  functions 
needed  in  equations  and  to  control  the  repetitive  integration  of  the 
parameterized  model;  for  example,  in  a  parameter  optimization  study.   On 
the  other  hand,  very  little  sophistication  is  required  for  models  involving 
only  straightforward  equations  and/or  the  use  of  predefined  library  elements, 
Users  unfamiliar  with  FORTRAN  can  employ  either  default  or  very  simple 
run-control  procedures;  for  example, 

PI  =  expression 

P2  =  expression 

CALL  RUN 

END 
The  nongraphical  dialect  of  MODEL  was  developed  to  allow  its  use 
at  other  installations  where  graphical  modeling  support  similar  to  that 
provided  locally  cannot  be  assumed.   Portability  is  not  achieved,  however, 
by  simply  providing  a  portable  mode  of  input.   Concern  must  also  be  given 
to  the  portability  of 
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1.  the  code  which  translates  the  user's  model  (i.e.,  the 
MODEL  compiler) , 

2.  the  code  into  which  the  model  is  translated  (i.e.,  the 
target  language  of  the  MODEL  compiler) , 

3.  the  code  which  exercises  the  translated  model  (i.e.,  the 
numerical  software). 

To  enhance  portability,  American  National  Standard  FORTRAN  was 
chosen  as  the  language  in  which  all  of  the  these  codes  ultimately  will  be 
written.   The  MODEL  compiler  produces  only  ANS  FORTRAN  and  work  is  underway 
to  remove  all  nonstandard  FORTRAN  from  the  numerical  software.   The  greatest 
difficulty  in  achieving  the  portability  of  ANS  FORTRAN  has  been  experienced 
in  coding  the  MODEL  compiler.   FORTRAN  is  not  a  convenient  language  for 
programs  which  consist  largely  of  data  structure  and  symbol  manipulation. 
For  this  reason,  the  compiler  was  not  coded  directly  in  FORTRAN,  but  rather 
in  a  locally  developed  language,  PLW  [1].   PLW  is  a  PL/l-like  language  which 
is  compiled  into  more  portable  FORTRAN.   Presently  PLW  produces  some  non- 
standard FORTRAN.   However,  a  future  implementation  of  PLW  will  employ  only 
ANS  FORTRAN,  permitting  the  software  package  to  be  distributed  more  widely. 

Even  the  use  of  only  ANS  FORTRAN  does  not  achieve  great  portability 
where  I/O  and  character  manipulation  operations  are  concerned.   When  MODEL  is 
implemented  at  a  new  installation,  it  will  usually  be  necessary  to  rewrite 
the  I/O  support  and  character  manipulation  routines  used  by  the  PLW-produced  code. 

The  portability  of  the  MODEL  compiler  produced  by  the  present 
implementation  of  PLW  is  restricted  to  machines  having  a  word  length  of  32  or 
more  bits.   Efforts  are  being  made  to  ease  the  word  length  restriction,  though 
the  numerical  software  will  usually  require  a  precision  of  48-60  bits  to  meet 
desired  accuracy  criteria.   The  subroutines  produced  by  the  MODEL  compiler 
employ  double  precision  arithmetic  as  does  the  numerical  software.   A  single 
precision  option  for  machines  with  sufficient  word  lengths  will  be  made 
available  in  the  future. 

The  MODEL  compiler  is  organized  into  overlays  to  ease  its  core 
storage  requirements,  but  a  large  amount  of  program  and  data  space  (roughly 
equivalent  to  48K  32-bit  words)  is  still  necessary. 
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The  portable  and  structurally  simple  text  file  accepted  by  the 
MODEL  compiler  allows  flexibility  in  the  modeling  environment.   This  text 
file  can  be  constructed  by  the  user  as  a  nongraphical  model  and  can  also  be 
interfaced  relatively  easily  to  graphics  and/or  library  support  software,  as 
is  done  locally.   Flexibility  in  the  model  execution  environment  is  provided 
by  allowing  the  translated  model  and  the  numerical  software  to  be  used  in 
any  fashion  reasonable  for  a  large,  FORTRAN-based  software  package.   The 
translation  of  the  user's  model  can  be  invoked  as  a  separate  job  or  as  the 
initial  step  of  a  ' compile-and-execute'  job.   The  integration  of  the  translated 
model  can  be  invoked  as  a  subroutine  from  any  user-written  FORTRAN  procedures, 
which  may  be  executed  in  batch  mode  or  on-line.   Efforts  have  been  made  to 
facilitate  the  alteration  of  the  translated  model,  the  run-control  program, 
or  any  other  FORTRAN  interfaces  to  the  simulation  study  at  the  FORTRAN  step, 
without  recompiling  the  model.   Listings  of  the  variable  dictionary  and  the 
default  run-control  program,  which  are  produced  by  the  MODEL  compiler  at  the 
user's  option,  are  invaluable  when  the  translated  model  or  the  run-control 
program  are  to  be  altered  after  the  MODEL  step. 

Our  long-range  goal  is  to  further  the  study  of  languages  for 
simulation  of  physical  systems.   The  efforts  reported  here  constitute  a 
certain  advancement,  but  the  language  has  not  yet  been  widely  used.   It 
will  certainly  profit  from  feedback  from  users  with  a  variety  of  types  of 
problems.   To  reach  a  wide  variety  of  users  it  is  necessary  to  distribute  the 
MODEL  compiler  and  numerical  support  to  a  number  of  installations.   This  will 
be  attempted  in  the  near  future.   The  compiler  has  been  implemented  and  tested 
and  the  testing  of  the  numerical  software  is  nearly  complete.   Some  further 
programming  is  required  to  finish  the  graphics  and  library  support  package 
so  that  feedback  can  also  be  obtained  from  users  of  the  local  graphical  dialect 

4.2.   Possible  Extensions  of  MODEL 
4.2.1.   Portable  Library  Support 

Library  support  is  invaluable  for  saving  element,  terminal  type, 
and  FORTRAN  function  definitions  between  modeling  sessions  and  for  allowing 
library  definitions  to  be  shared  by  several  users.   The  portable  dialect  of 
MODEL  presently  provides  no  library  support  because  this  software  must  be 
rather  inefficient  to  be  highly  portable.   However,  portable  library  support 
would  prove  useful  for  users  who  cannot  or  do  not  wish  to  code  library 
support  software  for  their  particular  installation. 
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A  portable  library  support  routine  (hereafter  called  an  LSR)  could 
be  written  in  PLW  and  compiled  into  FORTRAN  to  act  as  a  front  end  to  the 
MODEL  compiler.   The  libraries  (one  each  for  elements,  terminal  types,  and 
FORTRAN  codes)  would  consist  of  text  files  which  could  be  accessed  sequentially 
and  rewound  (i.e.,  tape  or  disk  files).   The  LSR  would  read  the  input  file 
(nongraphical  model),  recognizing  statements  such  as 

LIBRARY  ELEMENT  name 

LIBRARY  TYPE  name 

LIBRARY  FORTRAN  name 
which  might  appear  at  the  beginning  of  the  model  or  within  the  element 
definitions.   References  to  library  definitions  would  be  stored  internally 
in  tables  which  could  be  expanded  during  the  gathering  of  library  element 
definitions.   After  constructing  the  initial  tables  of  requested  library 
definitions,  the  LSR  would  read  from  the  element  library,  checking  the  name 
of  each  library  element  against  the  names  of  the  requested  elements.   Upon 
finding  a  desired  definition  the  LSR  would  copy  it  into  the  model  and  remove 
the  reference  from  the  library  element  reference  table.   During  this  copying 
operation,  the  LSR  would  note  any  references  to  other  library  definitions 
which  occur  within  the  library  element  and  add  them  to  the  appropriate  table 
if  they  are  not  defined  in  the  model  or  already  present  in  the  table.   Any 
subelements  invoked  by  the  library  element  would  also  be  handled  as  library 
element  references.   Due  to  this  dynamic  nature  of  the  library  reference 
tables,  a  number  of  passes  through  the  element  library  may  be  required. 
After  each  pass  the  element  library  would  be  rewound  and  read  again,  until 
all  necessary  library  elements  have  been  found  and  copied.   Any  library 
element  references  which  remained  in  the  table  for  an  entire  pass  through 
the  element  library  would  be  reported  as  unresolved.   After  the  processing 
of  the  library  element  references,  the  terminal  type  and  FORTRAN  code 
reference  tables  would  be  completed  and  these  libraries  would  each  be  read 
once  to  copy  the  necessary  definitions  into  the  model. 

The  LSR  might  also  recognize  statements  such  as 

SAVE  ELEMENT  name 

SAVE  TYPE  name 

SAVE  FORTRAN  name 
within  the  model  and  copy  any  definitions  referenced  by  these  statements 
into  the  appropriate  libraries. 


119 


4.2.2.  Other  Terminal  Variable  Types 

A  natural  question  concerning  terminal  variables  is  whether  there 
should  be  other  types  available  in  addition  to  E-  and  1-types.   As  previously 
reported  in  [2],  we  have  not  been  able  to  find  any  other  types  which  appear 
to  be  fundamental.   To  quote  from  [2]:   "If  a  variable  is  not  of  E-type 
(usually  representing  some  intrinsic  quantity  such  as  voltage,  pressure, 
position)  It  can  often  be  transformed  into  an  I-type  variable.   Since  the 
zero  sum  rule  at  nodes  is  a  form  of  a  conservation  equation,  choice  of 
variables  that  are  conserved  (e.g.,  momentum,  energy,  mass,  current)  will 
usually  give  an  I-type  variable.   For  example,  we  might  be  tempted  to  use 
PRESSURE,  FLOW,  and  TEMPERATURE  to  characterize  a  water  pipe  connection. 
However,  at  a  junction  of  more  than  two  pipes,  TEMPERATURE  is  not  of  either 
variable  type.   If  instead  we  use  HEATFLOW  (=  TEMPERATURE*FLOW) ,  this  is  an 
I-type  variable  because  heat  satisfies  a  conservation  law  in  the  absence  of 
other  energy  sources." 

"The  possibility  of  allowing  user-specified  equations  to 
characterize  the  terminal  variables  associated  with  nodes  was  also  considered. 
Since  there  does  not  seem  to  be  a  need  for  this  generality,  and  since  it  is 
possible  to  use  a  connective  element  which  can  contain  arbitrary  equations, 
this  idea  was  abandoned." 

4.2.3.  Higher  Order  Derivatives  and  Derivatives  of  Expressions 

In  many  cases  it  would  be  convenient  for  the  user  to  refer  to 
higher  order  derivatives  (e.g.,  y.")  and  to  derivatives  of  expressions 
(e.g.,  g'(y,  y '  ,  _t ) )  directly  without  having  to  introduce  auxiliary  variables 
(e.g.,  z  =  y.'  or  z  =  g(y_,  y '  ,  t ) )  .   This  feature  could  be  implemented  in 
MODEL  through  a  relatively  modest  programming  effort.   Auxiliary  variables 
would  still  be  required  since  the  numerical  software  cannot  solve  the 
equations  for  higher  order  derivatives  or  for  the  derivatives  of  expressions. 
However,  the  introduction  of  these  auxiliary  variables  could  be  handled 
automatically.   The  MODEL  compiler  already  Includes  facilities  for  internal 
generation  of  auxiliary  variables  and  equations,  which  are  sometimes 
introduced  for  the  sake  of  efficiency  or  numerical  stability.   This  makes 
it  quite  feasible  for  the  compiler  to  perform  transformations  on  user-written 
equations  such  as 

ffy_>  Z'»  S'(v_,  y_\  t),  t)  -  0  -►  fOy_,  y_f  ,  z\  t)  =  0  and  z  =  g(y_,  y_'  ,  t) 
where  g  represents  an  expression  or  derivative  and  z  is  an  automatically 
generated  auxiliary  variable. 
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4.2.4.   Additional  Array  Operators 

MODEL  provides  a  number  of  features  in  support  of  array  operations 
such  as  the  use  of  infix  operators  for  addition,  subtraction,  multiplication, 
and  inner  product  of  arrays  and  vectors,  an  array  differentiation  operator, 
and  FORTRAN  functions  which  can  operate  on  arrays  and  vectors  and  return 
nonscalar  results.    The  latter  allows  virtually  any  other  desired  array 
operation  to  be  accomplished  at  the  FORTRAN  level.   However,  some  further 
support  by  MODEL  would  be  convenient  for  the  user,  particularly  the  provision 
of  subscripting  in  equations.   Implementation  of  subscripting  would  require 
double  parentheses  for  references  to  subscripted  terminal  variables.   For 
example,  FL0W(1)  would  refer  to  the  scalar  flow  at  terminal  1  while 
P(l)(3)  would  refer  to  the  third  element  of  the  vector  P  at  terminal  1. 

If  subscripting  is  supported  in  the  equations,  users  will  want  to 
take  advantage  of  facilities  for  repeating  an  equation  several  times  with 
varied  subscripts.   Looping  operations  could  be  provided  but  macro-level 
operators  for  the  generation  of  equations  with  subscript  modifications  would 
be  more  in  keeping  with  MODEL'S  parallel  nature.   These  macro  operators  could 
be  provided  as  part  of  a  general  macro  interpretive  language  for  equations, 
but  a  general  macro  interpreter  would  probably  require  too  much  program 
space  in  the  MODEL  compiler  to  be  cost-effective.   The  provision  of  two 
macro-level  operators  which  we  will  call  REPEAT  and  INSERT  would  suffice  to 
support  array  operations  conveniently. 

The  REPEAT  operator  would  cause  an  equation  to  be  generated 
repeatedly  while  specified  subscripts  were  varied  over  a  specified  range. 
For  example, 

REPEAT(4  8  1)   A(3,  $)  =  0 
would  cause  the  generation  of  four  equations  in  which  the  subscript 
indicated  by  $  would  be  stepped  through  the  range  4  to  8  by  increments  of 
1.   It  would  be  useful  to  nest  the  REPEAT  operator  in  some  cases,  for  example, 

REPEAT(1  8  1  ;  $  8  1)   A($,  $$)  =  0 
(where  $  refers  to  the  outer  index  and  $$  to  the  inner  index  of  repetition) 
would  cause  all  but  the  lower  triangular  members  of  the  8x8  array  A  to  be 
set  to  zero. 

The  INSERT  operator  would  cause  terms  within  a  single  equation  to 
be  repeated  while  their  subscripts  were  varied  over  a  specified  range. 
For  example, 

INSERT(1  7  2+)   B($)  =  0 
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would  cause  B($)  to  be  repeated  while  $  was  stepped  from  1  to  7  by  increments 

of  2.   The  occurrences  of  B($)  would  be  separated  by  the  specified  operator 

+.   In  other  words,  the  expanded  equation  would  be  B(l)  +  B(3)  +  B(5)  +  B(7)  =  0. 

The  possibility  of  allowing  the  dimensions  of  array  variables 
declared  within  an  element  to  be  passed  as  parameters  to  that  element  was 
considered.   Such  dummy  parameters  would  have  to  be  replaced  by  constants 
rather  than  variables,  but  would  allow  different  dimensions  to  be  used  in 
various  instances.   However,  we  have  not  yet  encountered  an  application 
which  warrants  the  implementation  of  this  feature. 

4.2.5.   Additional  Strip  Terminal  Operators 

Present  features  for  generating  equations  involving  the  terminal 
variables  connected  to  a  strip  terminal  are  only  experimental  and  clearly 
inadequate.   The  NSTRIP  operator  is  useful  for  inserting  the  number  of 
connections  to  a  strip  terminal  into  a  function  reference,  but  the  available 
method  of  inserting  the  connected  terminal  variables  into  a  function 
reference  is  inconvenient  because  standard  FORTRAN  does  not  support  varadic 
functions.   At  the  very  least,  an  operator  which  copies  these  terminal 
variables  into  a  vector  is  needed.   This  would  allow  a  single  FORTRAN 
function  to  be  used — for  example,  to  compute  the  sum  of  the  connected 
variables — regardless  of  the  number  of  connections  to  the  strip  terminal. 

A  slightly  different  form  of  the  REPEAT  and  INSERT  operators 
described  in  the  previous  section  would  also  be  useful  for  the  generation 
of  equations  involving  strip  terminal  variables.   For  example,  a  user  might 
define  the  summing  element  of  Figure  4.1  using  a  strip  terminal  to 
accommodate  any  number  of  input  connections  without  shorting  them  together. 


^vW- 


^° 


Figure  4.1.   Strip  terminal  summing  element 
The  equations  which  define  the  behavior  of  this  element  when  terminal  1  is 
connected  to  terminals  n. ,  n  ~  , .  .  .  ,  n,  are 
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1.  VCtij)  -  I(n1)*R  =  V(0) 

2.  V(n2)  -  I(n2)*R  =  V(0) 


k.   VCn^)  -  I(nk)*R  =  V(0) 
k+1.   1(0)  +  I(n  )  +  I(nJ+...+   I(nk)  =  0 
Equations  1  through  k  could  be  generated  by  the  statement 

REPEAT(STRIP  1)  V($)  -  I($)*R  =  V(0) 
which  would  indicate  that  the  equation  is  to  be  generated  repeatedly  while 
the  terminal  ID  numbers  indicated  by  $  are  replaced  first  by  n-.  ,  then 
n „ , .  .  .  ,  n,  .   Similarly,  equation  k+1  would  be  generated  by  the  statement 

INSERT(STRIP  1  +)   1(0)  +  I($)  =  0 

4.2.6.  Logically  Structured  Blocks  of  Equations 

Presently,  each  conditional  THEN  and  ELSE  clause  can  contain  only 
a  single  equation.   Thus,  it  is  necessary  to  repeat  the  same  condition 
several  times  to  define  a  model  in  which  several  equations  change  at  some 
common  threshold  state.   In  such  cases  it  would  be  convenient  to  structure 
blocks  of  equations  in  conditional  clauses.   IF,  THEN,  and  ELSE  clauses  are 
recognized  in  a  module  of  the  PLW  compiler  which  calls  the  equation/condition 
parser  as  a  subprocedure,  so  it  would  be  relatively  easy  to  alter  this  code 
to  accept  any  number  of  equations  in  THEN  clauses,  followed  by  a  like 
number  in  the  ELSE  clause. 

4.2.7.  Initial  Values  and  Ranges 

Presently  MODEL  allows  only  one  initial  value  to  be  specified  for 
each  variable/derivative  pair  in  a  model,  due  to  the  manner  in  which  the 
steady  state  numerical  support  is  programmed.   However,  in  some  models  it  is 
most  convenient  to  specify  the  desired  initial  state  by  giving  initial 
values  for  both  a  variable  and  its  derivative.   It  would  also  be  useful 
in  some  cases  to  specify  a  range  of  values  in  which  a  variable  or 
derivative  is  to  fall  initially;  particularly,  when  the  equations  of  the 
model  are  undefined  outside  a  certain  range  and  when  more  than  one  mathematical 
solution  to  the  steady  state  exists.   This  type  of  initial  value  specification 
would  also  speed  the  calculation  of  the  steady  state  by  providing  a  first 
approximation  (i.e.,  the  midpoint  of  the  specified  range)  to  the  initial 
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value  of  the  given  variable  or  derivative.   Both  of  these  features  will  be 
implemented  in  MODEL  as  soon  as  they  are  supported  by  the  steady  state 
software.   Minimal  effort  will  be  necessary  for  MODEL  but  a  major  rewrite 
of  the  steady  state  routines  will  be  required. 

4.2.8.  Boundary  Values 

The  possibility  of  extending  the  numerical  support  to  include 
parallel  shooting  methods  for  the  solution  of  boundary  value  problems  in 
ordinary  differential  equations  is  presently  being  investigated.   If  this 
extension  is  made,  the  specification  of  boundary  values  will  be  implemented 
in  MODEL.   A  boundary  value  statement  would  have  much  in  common  with  an 
initial  value  statement.   Thus,  the  implementation  of  this  feature  in 
MODEL  should  not  be  difficult. 

4.2.9.  Additional  Output  Operators 

A  great  deal  of  output  flexibility  is  presently  available  at  the 
FORTRAN  level,  but  it  would  be  convenient  if  high-level  operators  for 
recording,  restoring,  and  filing  solution  histories  and  states  were  available 
without  extensive  user-supplied  FORTRAN  codes.   These  operators  could  be 
provided  as  a  set  of  system  subroutines  which  could  be  called  from  the  run- 
control  program.   For  example,  FORTRAN  subroutines  called  SAVE,  RESTORE, 
and  FILE  could  be  added  to  the  numerical  support  and  called  with  a  logical 
unit  number  as  their  argument.   SAVE  would  write  the  current  system  state  to 
the  specified  unit  and  RESTORE  would  read  the  state  on  the  specified  unit 
into  the  system.   A  call  to  FILE  would  cause  the  output  from  a  subsequent 
integration  to  be  recorded  on  the  specified  unit.   A  plot  package  interface 
would  also  be  very  useful  and  is  scheduled  for  implementation.   Desirable 
options  include  line-printer  plots,  cross-plots,  and  over-plots. 

4.2.10.  On-line  Simulation 

When  the  DRAGON  graphics  and  library  support  package  is  completed, 
modeling  at  the  local  installation  will  be  carried  out  interactively  under  a 
PDP-11  running  DRAGON.   However,  model  translations  and  simulations  are 
presently  limited  to  batch  mode  due  to  the  nature  of  the  link  between  the 
PDP-11  and  the  IBM  360  on  which  these  programs  are  currently  run.   Completed 
models  can  be  sent  from  the  PDP-11  to  the  IBM  360  for  translation  and 
simulation,  and  output  from  the  simulation  can  be  routed  back  to  the  PDP-11 
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and  subsequently  to  the  remote  terminal,  but  the  response  time  in  batch  mode 
may  be  quite  lengthy.   Work  is  presently  underway  to  replace  the  IBM  360  in 
this  configuration  with  an  INTERDATA  732.   When  a  rewrite  of  the  PDP-11-to- 
INTERDATA  7  32  link  driver  is  completed,  the  INTERDATA  can  be  used  in 
dedicated  fashion  to  support  the  simulation  package.   The  model  translation, 
FORTRAN  compilation,  and  simulation  steps  submitted  from  the  PDP-11  will  be 
handled  very  rapidly,  and  output  from  the  simulation  will  be  sent  across 
the  link  to  the  PDP-11  during  the  integration.   The  PDP-11  will  have  immediate 
access  to  this  output,  which  will  be  formatted  and  displayed  on  the  remote 
terminal  on-line. 

A  cursory  investigation  of  the  requirements  for  interactive 
simulation  at  the  local  installation  has  been  conducted.   The  ability  to 
display  solutions  on-line  will  be  available  soon,  as  described  above.   The 
other  principal  requirement  would  be  a  run-time  interpreter  capable  of 
altering  parameter  values  and  invoking  system  subroutines  (e.g.,  RUN,  CONTIN, 
SAVE,  RESTORE,  FILE)  in  response  to  commands  issued  by  the  user  at  a  remote 
terminal.   The  ability  to  display  current  values  of  model  variables  and  to 
change  the  output  variables  at  the  remote  terminal  would  also  be  useful. 
Implementation  of  these  features  will  depend  on  detailed  studies  of  their 
feasibility  and  cost-effectiveness,  which  have  not  yet  been  made. 
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NOTES 


FORTRAN  function  subprograms  can  return  only  scalar  results  but  MODEL 
allows  FORTRAN  subroutines  to  be  referenced  as  functions  to  compute  non- 
scalar  results.   See  section  3.5. 
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APPENDIX  A 
MODEL  TEXT  DIALECT  STATEMENTS  AND  THE  ORDER  OF  THE  INPUT  FILE 
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The  text-oriented  input  file  of  the  MODEL  compiler  consists  of 
four  sections  which  must  appear  in  the  order  below.   This  is  the  order  in 
which  MODEL  text  dialect  programs  must  be  formulated. 

Section  1:   Specification  of  the  highest  level  element  name,  independent 
variable  name,  logical  unit  number  and  title  of  the  output  file,  FORTRAN 
subprogram  syntax  definitions,  terminal  types,  and  MODEL  compiler 
options.   The  statements  in  this  section  can  appear  in  any  order.   This 
section  may  be  omitted  if  default  compiler  options  and  assumptions 
concerning  the  model  name,  independent  variable  name,  and  output  unit 
number  are  desired  and  no  output  title,  user-defined  FORTRAN  subprograms, 
or  terminal  types  are  required. 


general   form  of   statement 

page  where  described 

ANALYZE  modelname 

72 

RENAME  ind-var-name 

73 

UNIT  unit-no 

100 

TITLE  titles tring 

100 

FUNCTION  func-name  n-args 

102 

SUBROUTINE  func-name  n-args 

{RVECTOR  {d}\ 
CVECTOR  {d}\ 

Li 

ARRAY    {d     d2}} 

102 

TYPE  type-name  E({ename{  (d„ . 

,  d2)};}*) 

77 

I({iname{  (d   , 

,  d2)};}*) 

FLIST 

105 

MAP 

105 

ABORT 

108 

129 


Section  2:   Element  definitions.   The  elements  can  be  defined  in  any 
order.   The  statements  within  an  element  definition  may  appear  in  any 
order  with  the  exception  that  NON-DEFAULTS  and  SUB-CONNECT  statements 
must  follow  the  corresponding  SUB-ELEMENT  statement.   At  least  one 
element  must  be  defined. 


general  form  of  statement 

ELEMENT  elt-name   {parm{(d  3   d  )}{=def-exp};}* 

DEFAULTS  {parm{(d  ,   d   ) }{=def-exp} ; }* 

GLOBAL S  {global{(d  3   d2)};}* 

LOCALS  {looal{(d£3   d)};}* 

TERMINALS  {term-no  -term-no     {type}}* 

J.  Cl 

EXTERNALS   {term-no  -term-no   }* 

J.  Cs 

CONNECT  { term-no  -term-no   }* 
SUB-ELEMENT  sub-elt-name   {parm=exp;}* 
NON-DEFAULTS  {parm=exp ; }* 
SUB-CONNECT  {term-no}* 
EQUATIONS  {exp  =exp  r\}* 

or   IF  oond   THEN  exp  =exp 

{ELSE  IF  aond   THEN  exp  =exp   }* 
ELSE  exp  =exp 

or   IF  oond   THEN  STOP  {=n) 
INITIAL  {v ar=oonst-exp ; }* 
OUTPUT  {var^}* 


page  where  described 
71 
72 
73 
73 
75 
75 
79 
79 
79 
80 
89 
95 


98 

98 

100 


Section  3:   Table  function  definitions.   Table  functions  may  be  defined 

in  any  order.   This  section  may  be  omitted  if  no  table  functions  are  required 


general  form  of  statement 
TABLE  tab-no 


2i2  t2 


page  where  described 
104 


x   t 

— n  —n 
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Section  4:   Run-control  program  and  FORTRAN  interfaces.   If  nondefault 
run-control  is  specified,  the  MAIN  statement  must  be  the  first  statement 
of  this  section,  and  the  run-control  program  must  follow.   The  $DEFAULT 
statement  must  be  included  immediately  before  the  first  executable  statement 
of  the  user's  run-control  program  to  allow  MODEL  to  insert  COMMON  statements 
variable  declarations,  and  default  control  parameter  assignments  into  run- 
control  program.   When  the  run-control  program  is  to  be  compiled  separately, 
these  COMMON  statements,  declarations,  and  assignments  must  be  copied  by  the 
user.   FORTRAN  subprogram  source  codes  follow  the  run-control  program. 
Section  4  may  be  omitted  if  default  run-control  is  used  and  no  FORTRAN 
interfaces  to  the  model  are  required,  or  if  the  run-control  program  and 
other  FORTRAN  interfaces  are  to  be  compiled  separately. 

general  form  of  statement  page  where  described 

MAIN  130 

non- executable  FORTRAN  statements  of  run-control  program 

$DEFAULT  130 

executable  FORTRAN  statements  of  run-control  program 
other  FORTRAN  source  codes 

Appendix  C  shows  the  IBM  360  job  control  statements  which  invoke 
the  compilation  and  execution  of  a  MODEL  program  and  indicates  the  positions 
within  the  job  control  program  at  which  the  various  sections  of  the  input 
file  are  to  be  inserted.   Sections  1,  2,  and  3  of  the  input  file  follow  the 
job  control  statements  for  the  first  (input)  step  of  the  MODEL  compiler, 
MAP.   Section  4  of  the  input  file  follows  the  job  control  statements  for  the 
second  (expansion)  and  third  (output)  steps  of  MAP.   The  job  control 
statements  for  the  fourth  step  of  MAP  and  for  the  FORTRAN  and  model 
execution  steps  follow  section  4  of  the  input  file.   Any  data  cards  to  be 
read  by  the  run-control  program  or  other  user-supplied  FORTRAN  programs 
must  be  inserted  at  the  appropriate  point  in  the  execution  step  job 
control  program. 
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APPENDIX  B 
SAMPLE  MODEL  AND  OUTPUT 
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This  appendix  shows  the  MODEL  text-dialect  formulation  of  a  storm 
sewer  network  which  is  constructed  from  interconnected  elements  similar  to 
those  described  in  section  1.3.   Figure  B.l  is  a  graphical  representation 
of  the  network.   Rainfall  enters  from  the  source  elements  and  is  collected 
below  the  street  in  two  small  reservoirs.   The  water  in  these  reservoirs 
drains  into  a  large  reservoir  from  which  it  drains  out  of  the  network 
(e.g.,  into  a  stream).   The  purpose  of  the  simulation  is  to  determine 
whether  the  reservoirs  overflow  during  a  storm.   This  can  be  determined 
from  the  values  of  the  variables  which  represent  the  heights  of  the  water 
in  the  reservoirs. 

The  elements  used  in  this  network  differ  somewhat  from  those 
described  in  section  1.3.   The  fluid  sink  equation 

B(0)  =  FLOW(0)**2/(2*G*A**2)  +  H 
has  been  rewritten  as 

FLOW(O)  =  ABS(SQRT(2*G*A**2*(B(0)  -  H))) 
to  insure  that  the  flow  is  greater  than  zero  and  thus  is  directed  into 
the  sink  element.   In  addition,  two  new  elements  are  employed.   The  cap 
element  is  used  to  plug  an  unconnected  outlet  by  setting  the  flow  through 
it  to  zero.   The  drain  element  is  similar  to  the  sink  element  but  includes 
another  terminal  and  equation  to  allow  the  drainage  flow  to  be  directed 
into  another  element  (e.g.,  the  large  reservoir). 

The  MODEL  text-dialect  formulation  of  this  network  and  the  network 
dictionary,  run-control  program,  and  output  subroutine  RECORD 
produced  by  the  MODEL  compiler  are  shown  below.   The  dictionary  includes  a 
node  map  which  identifies  the  nodes  of  each  element  by  listing  the  ID  numbers 
of  the  terminals  connected  to  each  node.   For  each  external  terminal  of  the 
node  a  different  ID  number  is  listed  on  the  following  line.   This  is  the  ID 
number  by  which  the  external  terminal  is  known  in  the  next  higher-level 
element.   These  numbers  permit  the  user  to  trace  external  connections  through 
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the  node  map  for  the  higher-level  element.   Since  variables  on  one  terminal 
will  be  either  equivalent  to  or  the  negatives  of  the  corresponding 
variables  of  a  connected  terminal,  FORTRAN  variables  are  not  assigned 
for  every  terminal  variable  of  the  network.   For  example,  only  one  FORTRAN 
variable  is  assigned  for  each  E-type  terminal  variable  on  any  connected 
set  of  terminals.   Thus,  the  node  map  is  very  useful  for  tracing  terminal 
variables  of  the  network  to  the  corresponding  FORTRAN  variables  of  the 
integration. 
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.  18  2  13, 


Figure  Bl.   Storm  sewer  network. 
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%   STORM  SEWER  NETWORK  TEXT  DIALECT  SOURCE  FILE 

ANALYZE  SEWER 

TYPE  FLUID  T(B)  I (FLOW) 

MAP 

FLIST 

TITLE        STORM  SEWER  LEVELS 

ELEMENT  SEWER 

GAMMA=62.43  ;  G-32. 
TERMINALS  1-9  FLUID 
RLOPALS  GAMMA  ;  G 

SUB-ELEMENT  SOURCE  OAREA=1000. 
SUB-CONNECT  1 

SUB-ELEMENT  SOURCE  OAPEA=1000. 
SUB-CONNECT  <" 

SUB-ELEMENT  RESEPV  AS=100.  ;  HINIT-5. 

"<1  =  .75  ;  Kl-5.  ;  A2-.75  ;  H2=5. 
SUB-CONNECT  1  2  3 

SUB-ELEMENT  RESERV  AS=100.  ;  HINIT-5. 

A1-.75  ;  Kl-5.  ;  n2=.75  ;  H2-5. 

SUR-CONNECT  4  5  6 

SUB-ELEMENT  CAP 
SUB-CONNECT  2 

SUB-ELEMENT  DRAIN  A-.75  ;  H.-5. 
SUB-CONNECT  3  7 

SUB-ELEMENT  DRAIN  A=.75  ;  M-5. 
SUR-CONNECT  5  7 

SUB-ELEMENT  CAP 

SUB-CONNECT  6 

SUB-ELEMENT  RESERV  Ac=1000.  ;  HINIT-O. 

"1=1.  ;  Kl-O.  ;  ^2-1.  ;  H2-0. 
SUB-CONNECT  7  8  9 

SUB-ELEMENT  CAP 
SUB-CONNECT  8 

SUB-ELEMENT  SINK  A-l .  ;  H=0. 
SUB-CONNECT  9 

%   PRIMITIVE  ELEMENTS 

ELEMENT  SOURCE  OAREA 

RAINRATE= ( - . 05*TIME*TIME+360.*TIME ) /7. 776E7 
FLOW(0)--RAINRATE*OAREA 

%   THE  RAINFALL  RATE  IS  REPRFSFNTFD  BY  A  PARABOLA  OPEN  TO  -Y  AXIS 


136 


c  AT  TIME=0  1AINRATE=0 

%   AT  TIME=3600  (1  HOUR)  MAX  RAINRATE  OF  6IN./HR.  IS  REACHFP 

%   AT  TIMF=7200  (2  HOURS)  RAIMRATE=0  AGAIN 

TERMINALS  0  FLUID 

EXTERNALS  0 

LOCALS  RAINRATE 

ELEMENT  RESERV  AS  ;  HINIT  ;  A1  ;  HI  ;  42  ;  H2 
!IS'*AS=Fl.0W(0)+FL0W(l)+FL0l'(2) 
V1=FL0W(1)/A1 

V2=FLOW(2)/p.2 

r(l)=Vl*Vl/(2*G)+Pl/GAMMA+Hl 

B(2)=V2*V2/(2*G)+P2/GAMMA+H2 

R(1)=HS 

B(2)=HS 
INITIAL  HS=I!INIT 
OUTPUT  HS 

LOCALS  HS  ;  VI  ;  PI  ;  V2  ;  P2 
TERMINALS  0-2  FLUIO 
EXTERNALS  0-2 

ELEMENT  CAP 

FLOW(0)*0 

TERMINALS  0  KLUID 
EXTERNALS  0 

FLEMFNT  DRAIN  A  ;  H 

FL0W(0)+FL0''J(1)=0 

FL0W(0HBS(SORT(2*G*A*A*(B(0)-H))) 
TERMINALS  0-1  FLUIO 
EXTERNALS  0-1 

ELEMENT  SINK  A  ;  H 

FLOW(OKBS(SOPT(2*G*A*A*(B(0)-H))) 
TERMINALS  0  FLUID 
EXTERNALS  0 


0/   || 


L'SER-Sl'PPLIEO  MAIN  PROGRAM 


7, 

MAIN 

".' 

S^EFAULT 

% 

TST0P=7200. 

m 

!J1V\X=60. 

Of 

C0MINT=60. 

r 

DEL=1.0-9 

01 

EPS=l.n»-4 

0.' 

CALL  RUN 

% 

END 

%   NETWORK  DICTIONARY  PRODUCED  BY  MODEL  COMPILER 
DICTIONARY  -  NODE  MAP 
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ELEMENT  SEWER. SOURCE (1) 

NOOE(O):  0, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  10, 


ELEMENT  SEWER. S0URCE(2) 

HODE(O):  0, 

IDENTICAL  TERMINALS  If!  ELEMENT  ABOVE:  11, 


ELEMENT  SEWFP.RESERVfl ) 

NODE(O):  0, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  12, 

MODE(l):  1, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  13, 

N0DE(2):  2, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  14, 


ELEMENT  SEWER. RESERV(2) 

NODE(O):  0, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  15, 

NODE(l):  1, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  16, 

N0DE(2):  2, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  17, 


ELEMENT  SEWER. CAP(l) 

NODE(O):  0, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  18, 


ELEMENT  SEWER. DRAIN(1 ) 

NODE(O):  0, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  19, 

NODE(l):  1, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  20, 


ELEMENT  SEWER. DRAIN (2) 

f,ODE(D):  0, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  21, 

M0DE(1):  1, 

IDENTICAL  TERMINALS  IN  ELEMFNT  ^nVE:  22, 


ELEMENT  SEWER. CAP (2) 
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MODE(O):  0, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  23, 


ELEMENT  SEWER. RFSERV(3) 

NODE(O):  0, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  24, 

NODE(l):  1, 

IDENTICAL  TERMINALS  IN  ELEMENT  AROVE:  25, 

N0DE(2):  2, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  26, 


ELEMENT  SEWER. CAP (3) 

NODE(O):  0, 

IDFNTICAL  TERMINALS  IN  ELEMENT  AROVE:  27, 


ELEMENT  SEWER. SINK(1 ) 

MODE(O):  0, 

IDENTICAL  TERMINALS  IN  ELEMENT  ABOVE:  28, 


ELEMENT  SEWER(l) 

•JODE(l):  1,12,10, 

N0DE(2):  2,18,13, 

M0DE(3):  3,19,14, 

N0DF(4):  4,15,11, 

N0DE(5):  5,21,16, 

N0DE(6):  6,23,17, 

N0DE(7):  7,24,22,20, 

NODE(B):  8,27,25, 

NODF(;;0:  9,28,26, 


DICTIONARY  -  VARIAPLE  MAP 
ELEMENT  SEWER(l) 


GLOBAL  VARIABLES 

OUTPUT  NAMFS 

SAMMA 

62.43^0 

32. DO 

TERMINAL 

VARIABLES 

OUTPUT  NAMES 

FLOW(IO) 

ZT(3) 

FLOW(ll) 

ZT(5) 

FL0W(12) 

-7T(3) 

FL0W(13) 

-0 

FL0W(14) 

ZL(1) 
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FLOW 
FLOW 
FLOW 
FLOW 
FLOW 
FLOW 
FLOW 
FLOW 
FLOW 
FLOW 
FLOW 
FLOW 
FLOW 
FLOW 


15) 
16) 
17) 
18) 
19) 
20) 
21) 
22) 
23) 
24) 
25) 
26) 
27) 
28) 


-ZT(5) 

ZL(4) 

-0 

0 

-71(1) 

ZL(1) 

-ZL(4) 

ZL(4) 

0 

ZL(7) 

-0 

ZL(8) 

-ZL(8) 


ELEMENT  SEWER. SOURCE (1 ) 


LOCAL  VARIABLES 
RAINRATE 

PARAMETERS 
OAREA 


OUTPUT  NAMES 
ZT(2) 

OUTPUT  NAMES 
1000. HO 


TERMINAL  VARIAPLES  OUTPUT  NAMES 
R(0)  NONE 


ELFMENT  SEWER. S(HIRCE(2) 


LOCAL  VARIABLES 
PAINRATE 


OUTPUT  NAMES 
ZT(4) 


PARAMETERS 
OAREA 


OUTPUT  NAMES 
1000.H0 


"ERMINAL  VARIAPLES  OUTPUT  NAMES 


«(0) 


NONE 


ELEMENT  SEWER. RESERV(l) 


LOCAL  VARIAPLES 

CUTPl'T  f!AMES 

HS 

7Y(1) 

VI 

ZG(1) 

PI 

7L(2) 

V2 

7Y(2) 

P2 

7L(3) 

PARAMETERS 

OUTPUT  NAMES 

5.S 

100.00 

mm 

5.n0 

M 

.75!1il 

Ml 

5.  JO 

A2 

.7500 

140 


H2  5.00 

TERMINAL  VARIABLES  OUTPUT  NAMES 

BO)  ZY(1) 

B(2)  ZY(1) 


ELEMENT  SEWER. RESERV(2) 


LOCAL  VARIABLES 

OUTPUT  NAMES 

HS 

ZY(3) 

VI 

7Y(4) 

PI 

ZL(5) 

V2 

ZG(2) 

P? 

ZL(6) 

PARAMETERS 

OUTPUT  NAMES 

AS 

100.00 

HIMIT 

5.00 

Al 

.7500 

HI 

5.00 

A2 

.7500 

H2 

5.00 

TERMINAL  VARIABLES  OUTPUT  NAMES 
B(l)  ZY(3) 

B(2)  ZY(3) 


ELEMENT  SE'-'ER.CAP(1 ) 


ELEMENT  SEWER. 0RAIN(1 ) 

PARAMETERS         OUTPUT  NAMES 
A  .7530 

H  5.^0 

TERMINAL  VARIABLES  OUTPUT  NAMES 
B(l)  NONE 


ELEMENT  SEWER. DRAIN(2) 

PARAMETERS         OUTPUT  NAMES 
A  .7500 

H  5.  JO 


ELEMENT  SEWER.CAP(2) 

ELEMENT  SEWER.?ESERV(3) 

LOCAL  VARIAP1.ES  OUTDUT  NAMES 


141 


HS 
VI 
nl 
V2 
P2 

ZY(7) 
ZG(3) 
ZL(?) 
7Y(3) 
ZL(10) 

PARAMETERS 

OUTPUT  NAMES 

AS 

TOOO.no 

HINIT 

O.DO 

M 

1.00 

HI 

O.DO 

A  2 

l.DO 

H2 

O.PO 

TERMINAL  VARIABLES  OUTPUT  NAMFS 
B(l)  ZY(7) 

B(2)  ZY(7) 

ELEMENT  SEWER. CAP(3) 


ELEMENT  SEWER. SINK(l) 

PARAMETERS         OUTPUT  NAMES 
A  1 .  ^0 

H  O.i^O 


GENERATED  VARIABLES  OUTPUT  NAMES 
SUB  ZY(5) 

SUB  7Y(6) 

SUP  ZY(9) 


%   RUN-CONTROL  PROGRAM  PRODUCFO  BY  MOPEL  COMPILER 

C0MM0N/VARS/7Y(9),ZD(9),ZDD(7t9)tZL(10),ZT(5),ZG(3) 
COMMON/SYSPRM/HMIN,HMAX,EPS,DEL,TSTART,TSTOP,COMINT,ISTOP 
DOUBLE  PRECISION  ZY("),ZD(9) ,ZDP(7,9) ,ZI  (10) ,ZT(5) ,ZG(3) 
+,HMINtHMAXtEPStDELiTSTART,TST0PiCOHINT 

p*** 

C***  DECLARATIONS  FOR  SOURCE  NAMES  r'F  GLOBAL  AMD  LOCAL  VARIABLES 

C***  AND  nARAMFTFRS  ^F  THE  HIGHEST-LEVEL  ELEMENT  APPEAR  HFPF  WHEN 

(:***  PRESENT  IN  THE  MODEL  AND  WHEN  NOT  EOUAL  TO  A  CONSTANT, 
p*** 

C***  FOUIVALENCE  STATEMENTS  MAPPING  SOURCE  NAMES  TO  INTEGRATION 

C***  VARIABLES  APPEAR  HERE. 
^•** 

C***  USER'S  NON-EXECUTABLE  RUN-CONTROL  STATEMENTS  APPEAR  HERE 

C***  DEFAULT  VALUES  FOR  SYSTEM  CONTROL  PARAMETERS  FOLLOW 
HMIM=l/)-6 
HMAX-1.0-2 
EPS-l.D-5 


***• 
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PEL=l.n-5 
TSTART=0.HO 
TST0P=1.H0 
C0MINT=1.0-2 
ISTOP=0 
USER'S  EXECUTABLE  RUN-CONTROL  STATEMENTS  FOLLOW 
TSTOP=7200.PO 
"MAX=60.r>0 
COM I NT= 60. nn 
PEL=1.P-Q 
FPS=l.D-4 
CALL  RUN 
FF!D 


%   OUTPUT  SUBROUTINES  PRODUCED  EY  MODEL  COMPILER 

SUBROUTINE  RECORD(INIT,IUNIT,N,A) 

C  RECORD  '/RITES  THE  N  OUTPUT  VALUES  IN  ARRAY  A  TO  UNIT 
C  IUMIT  WHEN  INIT  NOT  EQUAL  ZERO.  WHEN  INIT  EQUAL  ZERO 
C  RECORD  "RITES  THE  TITLE  AND  LABELS 
DOUBLE  PRECISION  A(N) 
IF  (INIT."E.O)  GOTO  9000 
WRITE (IUNIT.l) 
1  F0RMAT(1H,29X,49HTITLE        STORM  SEWER  LEVELS 
+  ,23f!  ) 

WRITE(IUNIT,2    ) 
2     F0RMAT{1H,9X 
+.8HTIME    ,13X 
+.8HHS     ,13X 
+.8HHS      ,18X 
+,8HHS     ,18X 

+) 

RETURN 
9000  '!RITE(IUNIT,9100)  A 
9100  F0RMAT(1H,5026.16) 

RETURN 

END 

SUBROUTINE  REP0RT(7G,7T,7L,ZY) 
C  REPORT  COPIES  THE  OUTPUT  VARIABLES  INTO  ARRAY  A 
C  AND  nASSES  A  TO  SUBROUTINE  "ECORD  FOR  OUTPUT 

DOUBLE  PRECISION  ZG(1 ),ZT(1 ),ZL(1 ),ZY(1 ),A(4) 

n(l)=7T(l) 

*.(2)-ZY(l) 

*•  3)«ZY(3) 

.r(4)  =  7Y(7) 

CALL  PEC0RD(1,£,4,A) 

RETURN 

END 


143 


APPENDIX  C 
IBM  360  BATCH  MODE  JOB  CONTROL 


144 


This  appendix  lists  and  describes  an  IBM  360  job  control  program 
which  performs  a  MODEL  compilation,  FORTRAN  compilation,  and  model  integration 
as  a  sequence  of  steps  in  a  single  batch  mode  job.   This  job  control  program 
is  included  here  to  illustrate  the  steps  to  be  executed,  the  necessary 
communication  between  these  steps  (i.e.,  file  I/O),  and  the  various  input 
streams  for  MODEL  code,  FORTRAN  code,  and  data  cards.   It  is  not  necessary 
to  adhere  to  the  job  control  given  here  to  use  the  MODEL  package.   For 
example,  the  package  can  be  used  on  other  computers,  and  tape  files  can  be 
used  instead  of  disk  files.   It  is  also  possible  to  perform  the  necessary 
steps  as  a  sequence  of  jobs.   In  this  case  the  job  control  program  shown 
here  would  be  split  into  two  or  more  parts  (e.g.,  one  job  which  performs 
the  MODEL  compilation,  a  second  which  performs  the  FORTRAN  compilation, 
and  a  third  which  performs  the  model  integration).   When  this  is  done,  the 
compiled  codes  must  be  written  to  permanent  files  instead  of  temporary  ones 
such  as  shown  here. 

The  job  controls  used  for  MODEL  compilation,  FORTRAN  compilation, 
and  model  integration  are  described  briefly  below.  The  job  control  program 
is  listed  at  the  end  of  this  appendix. 

The  job  control  shown  here  uses  two  in-line  procedures,  WGO  and 
WFORT.   WGO  invokes  the  IBM  loader  to  link-edit,  load,  and  execute  one  or 
more  object  decks  from  the  file(s)  associated  with  SYSLIN.   WGO  is  used  to 
execute  the  MODEL  compiler  and  the  numerical  software.   WFORT  invokes  the 
FORTRAN  G  compiler  on  the  file(s)  associated  with  SYSIN  and  writes  the 
object  deck  for  these  codes  to  the  disk  file  &&LINKFILE.   It  is  used  to 
compile  the  output  from  the  MODEL  compiler. 

The  MODEL  compiler  is  a  four  step  process.   Object  decks  for  the 
four  steps  are  catalogued  in  the  data  set  USER.P3503.LMOD  under  the  names 
MP1,  MP2,  MP3,  and  MP4  and  are  executed  by  WGO.   Object  decks  10$  and 
PLFSUBSX  from  the  same  catalogued  data  set  are  also  included  in  each  step. 
10$  contains  the  10  support  routines  and  PLFSUBSX  contains  the  character 
manipulation  routines  used  by  the  MODEL  compiler. 

The  MODEL  compiler  uses  I/O  files  declared  as  FORTRAN  logical 
units  5,  6,  and  91  through  99.   Unit  5  is  used  for  the  input  streams.   The 
MODEL  language  input  (sections  1,  2,  and  3  of  the  input  file  as  described 
in  Appendix  A)  follows  the  first  step  of  the  MODEL  compiler.   FORTRAN  code 
which  is  passed  through  the  MODEL  compiler  (section  4  of  the  input  file) 
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follows  the  third  step  of  the  MODEL  compiler.   The  model  source  listing  and 
any  error  messages  which  are  produced  are  written  to  unit  6.   The  fixed 
portions  of  the  MODEL  error  messages  are  catalogued  as  USER. P3503. MACROS (ERMW) 
and  are  read  as  needed  from  unit  93.   Temporary  disk  files  are  used  for  the 
remaining  units.   Units  91  and  92  are  used  for  communication  between  steps. 
Units  97,  98,  and  99  are  used  as  intermediate  files  during  the  construction 
of  the  FORTRAN  output,  which  is  written  in  final  form  on  units  95  and  96. 
Unit  95  contains  the  run-control  program,  any  other  FORTRAN  submitted  by 
the  user,  and  subroutine  RUN.   Unit  96  contains  the  other  FORTRAN  subroutines 
produced  by  MODEL.   The  model  dictionary  is  produced  on  unit  94.   The 
dictionary  and  the  FORTRAN  codes  are  copied  to  unit  6  if  requested  by  the  user, 

The  FORTRAN  output  of  the  MODEL  compiler  is  compiled  by  WFORT.   The 
input  file,  SYSIN,  consists  of  the  disk  files  &&BLK95  and  &&BLK96  created 
by  MODEL  through  FORTRAN  units  95  and  96.   User-supplied  FORTRAN  can  also  be 
included  in  this  step.   The  object  code  produced  by  the  FORTRAN  compiler  is 
written  to  the  temporary  disk  file  &&LNKFILE. 

The  object  deck  representing  the  model,  &&LNKFILE,  is  linked  with 
an  object  deck  of  the  numerical  software,  USER.P3503.LMOD(NSP) ,  and  the 
model  is  integrated  as  the  final  job  step.   FORTRAN  unit  5  is  used  for 
user-supplied  data  cards  and  unit  90  is  used  for  temporary  disk  storage.   In 
the  near  future  the  integration  step  will  be  replaced  by  two  steps,  the 
first  of  which  will  perform  the  steady  state  analysis  and  certain  sparse 
matrix  operations  and  the  second  of  which  will  perform  the  integration. 
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//iiodel    jo7'. 

/*id         ps=        ^ame-'usfr' 

/''•ID  CODE= 

/*ID  REGION=200r.,TI?*E=      ,IOREQ=  ,LIIIES= 

***        PROCEDURE   DEFINITIONS 
*** 

//"go       r^oc  liefil2=Mjser.f3503  j,mod?  ,ppog=tb>!Loadr, 

//  LIBFILE-'RYSIVTCLLIB ' ,OBJBISF=FASS 

//GO     EXEC  PGM=&rEOG,REGION=56E,PARM=LET 

//FT?6F00]  DD  SYSOUT=/ 

//SYEEIE    DD  DS:?=£LIBFIL2,DISP=ST:R 

//         DD  D5i:=SYSl.FORTIJB, DISPOSER 

//         DD  DSN=SYSl.FORTUOI,DI5P=SER 

//         ?T>  DSN=SLIBFILE,DISP=SER 

//SYSLIN   DD  DSN=£&LNKFILE,UNIT=DISK, 

//  SPACE=(TPi<:,l),DISP=(MOD,&OEJDISF) 

//         "iD  DDSAME-SYSIW 

//SYSLOUT  DD  SYSOUT=A 

//EYSPRINT  DD  SYSOUT=A 

//SYSUDUMP  DD  SYSOUT=A 

//       PEND 

//TORT      PROC  LEVEL-G 

//FORT        EXEC  PGM=UIFORT&LEVEE,REGION=116K 

//EYSLI1I        DD  DSN=&&LNKFIEE,DISP=(nOD,FASS)  , 

//  SPACE=  (TRK,  (20,20)  )  ,UNIT=BISK,DCB=BLKSIZE=400 

//EYEFRINT  DD  SYSOUT=A 

//PYSPU1TC!!   DD  DUIEIY 

//SYS7DIP     DD  DSN=&&SYSUT3,UNIT=DISK,SPA.CE=(800,50, ,  , ROUND) , 

//  DCB=(RECFI!=FB,LRECL=SO,BLEEIZE=SOO) 

//EYEUT1   DD  DSN-S&SYSUT]  ,U;atI7=DIST:,SPACF.=  (1050,50,  ,  .ROUND) 

//SYSUT2   !')D  DSN»&&SYSUT2,UNIT=DISK,SPACE-(4096t30, ,  ,ROUND) 

//       PEND 

*** 

***    4  PAES  MODEL  COMPILATION 
*** 

//PI  LXEC  '7GO,PARM=,LETlEP=PLT.vTf^AIN'  ,REGION=125K 

//SYSLIN   DD  DSK=USER.P3503.L!!OP(KP1)  ,DISP=SKR 

//         DD  DSN=USER.P3503.LKOD(IO$),DISP=SI'R 

//         !  D  DEN=USFR.P3503.LHOD(PLFEUBSX) ,BISP=SER 

//I  T93F001  DD  DSN=USER.F35C3. MACROS (ERMW)  , 

//  LABEL=(,  ,,III),DISP=SHR,DCE=BUFNO=l 

//]  T96i  ooi  dd  dsnai:e=s&eek96,u:,tit=eyeda,space=(tr:c,(io,2)), 

//  DCB=  (PvECFM=FB,LPECL=72,BLKSI2E=1440,EUF:TO=1)  , 

//  :)ISP=  (NET\  PASS) 

//FT91F001  DD  DSKAMT-&&3LK01,UniT-fiY5T)\,SPACE-(TRK,  (10,2)), 

//  DCB=(PJCCFM=VS,BLKSIZE=1230,EiTN0=l),DISF=(NEtf,PASS) 

//FT92r001   DD  DSNAME=a&BLK92,UNIT=SYSDA,SPACE=(TRK, (10,2)) , 

//  riCE» (EECKi«V£  ,BLKSIZE=3510,Bl  FNO=l)  ,DISP=(NEU,PASS) 

//,  T05F001    i  D  * 
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Aft* 
ft** 

//?2  exec  • 

//FYSLPJ 

// 

// 

//FT93F001 

// 

//FT94F001 

// 

// 

//FT91F001 

// 

//FT92F901 

// 

//:s3  :.xic  ■ 

//rYrLI!I 

// 

// 

//FT?3r001 

// 

//FT94F001 

// 

// 

//FT?5r001 

// 

// 

//FT96F001 

// 

// 
//FT97^001 

// 
// 
//FTOfjfOO] 

// 

// 

//FT31FQ01 
// 
//FT92F001 

// 

//FTO5V03] 
*** 

*** 

//r4  LXEC  ' 

//SYSLIN 

// 

// 

//FTC5F001 

// 

// 

//  'T96F001 

// 

// 

//FT99T'001 

// 


!IODi:L  LANGUAGE  INPUT  STATEMENTS 


:co 

!)D 
DD 

;:n 


ED 

:D 

:GO 
DD 
DD 

D 

DD 


[JD 


ID 


>D 


DD 

DD 
i  e: 


, FARM- '  LET, EF-PL-.JMAIN ' , REGION-200K 
DSN=USER.P3503.L*fOD(MP2),DISP=SIIR 
DSN=USER.F3503.LMOD(IO$),DISF=FHR 
DSW«l'SER.P3503.U-IOD(PLF!5lTESX),DISP-SIiiE 
DSN-USER .  "'3503 . : IACROS  (ERMW)  , 
LABEL- (, ,  ,!:■:)  ,DISP=EUR,DCE=EUFN0=1 
DSNAfE=&&ELK94,UNIT=FYSPA ,  SPACE=  (TRK,  (lp ,  2) ) , 

rcb- (p.ecfm-fb , lrecl-30 , elkfize-1600 , bufno-l ) , 

disp=(:tew,paS3) 

dsname=£sblk91,unit=sysda, space- (trk,  (10,2)), 

DCB- (RECFM-vs,BLKSIZE=  1230, BUF*IO-l),DISP=(OLD, PASS) 
DSR/\ME=S:&ELK92,UniT=SYSDA,  SPACE- (TRK,  (10,2) ) , 
DCE=(IIECFM=VS,BLKSIZF=3 510, BUFNO-1) ,DISP- (OLD, PASS) 
,PARlT=,LET,EP=?LvJT'IAIN,,RECIOK=200K 

ds!I-user.P3503.lmod(l;p3),disp=she 
dsimjser.p3503.lmod(io$),disp=sne 
ds>!=user.p3503.lm0d(plfsuesx)  ,dtsp=<:'  ': 

DSN-USER. E3503. MACROS (ERMU)  , 

LABEL-(,,,IN),DISP=S1IR,DCB=EUFN0=1 

DSNAME=&&BLK94,UNIT=SYSDA, SPACE- (TRK, (10,2)) 

DCB=(RECFM=FB,LPJ:CL=S0,ELKSIZE-1600,EUFNO=l) 

OISP- (MOD, PASS) 

DS:iAME=££BLK95,UiIIT=SYSDA,  SPACE- (TRK,  (10,2)) 

?CB=(EECFM=FE,LRECL=72,3Lr.SIZE=1440,BUFI-TO=l) 

r>ISP«(NE7,PASS) 

DSNAME=&&BLK96,UNIT=SYSDA,SFACE- (TRK, (10,2)) 

DCB-(RECFM=FB,LRECL=72,ELKFIZE=1440,BLFNO=1) 

nisp=0  oo, pas?) 

DS?7AME=&&BLK97,U1TIT=SYSDA, SPACE-  (TRK,  (10,2)) 
DCB=(RECF!I=FE,LRECL=72,BLKSIZE=1440,EUFITO=1) 
[3ISr=(KEM,  DELETE) 

DSKAME=fx&ELK93,UIUT=SYSPA, SPACE- (TRK,  (10,2)) 
DCE=(RECFT^Fr,LRECL=72,BLKSIZE=1440,BUF  10=1) 

DSNAME-  C.&BLK91 ,  UNIT-SYSDA  ,  S  F  \CE=  (TRR  ,(10,2)), 

■)CB=(RECFM=VS,ELKFIZE=1230,EUFnO=l),DISP=  (OLD,  PASS) 

DSNAME=S&3LK92,UNIT=SYS1  ■*• , cr ACE-  (TRK,  (10, 2) ) . 

'  CE=(RECF?:=VS,3LI'.SIZE=3510,BUF"O=l),DISP- (OLD, PASS) 
* 

ER-:  UPPLIED  FORTRAN 


r-0,P1\PJt=,LET,EP=FLT.7MAIN,,REGI01J-150E 


DD 

DD 

DD 


>D 


DSE-l  f?ER.r3503.LMODClP4),DISP-Fnr 

i"  "  -USEP.F3503.LMOD(IO$),DISP=SFE 

DS  f-USER.1  3503.LMOD(PLFSUBSX),DISP=SIIR 

DS:\AME=&&BLK95,Ui:iT-SYSDA, SPACE- (TRK,  (10,2)) 

»CB=(FECFH-FB,LRECL=72,BLKST.ZE=1440,BUFNO=l) 
L*ISP- (MOD,  PASS) 
DSNAMJE=&&BLK96,U?JIT«SYSDA, SPACE- (TRK,  (10,2)) 

iCB=(PJECFM-FB,LRECL-72,BLKSIZE»1440,BUFNO=l) 

ISP- (MOD, PASS) 
DSNAME=&&BIiC99,UNIT-SYSDA, SPACE- (TRK, (10,2)) 
!>CE=(RECFIt-FB,LRECL=72,BLKSIZF-1440,BUFI\,0-l) 
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//  DISP= (NEW, DELETE) 

//FT91F001   V>}  DSNANF=£&BLK91,UNIT=SYSDA,SPACE=(TRK,  (10,2))  , 

//  DCB=(RECFtt=VS,3LKSIZE=l 230, BUFNOl)  ,DISP=  (OLD, DELETE) 

//FT92F001  DD  DSNAME=&&BLK92,m-TIT«SYSDA,  SPACE- (TRK,  (10,2))  , 

//  '>CB=(RECFM=VS,BLX?IZE=3510,BEFNO=1),DIPS= (OLD, DELETE) 

***   FORTRAN  COMPILATION 
*** 

//    EXEC  T.T0RT,PARM='  !0S0URCE,N0!IAP ' 

//SYFP;    DD  DSNAME=£aBLX95,UNIT=SYSDA,SPACE=  (TRK,  (10,  2)  )  , 

/ /  ~JCB=  (RECF* i=FB , LRECL=7 2 ,  BLXSIZE=1440 , BUFNO=l)  , 

//  ^IPP= (OLD, DELETE) 

//         9D  Dr^;A.ME=^&BLE96 ,UKIT=CYSDA, SPACE=  (TRK,  (10, 2) )  , 

//  PCB=  (RECFM=VB,LRECL=72,BLKSIZE=1440,BUFi;O=l)  , 

//  ^ISP= (OLD, DELETE) 

***        y^d      * 

***        USER-SUPPLIED  FORTRAH 
*** 

***    MODEL  INTEGRATION 
*** 

//    EXEC  VT,0,  PARM=' LET,  EP=  IAIN',  REOION=150K 

//CYPLIN   DD  DSN=r<&LNKFILE,UNIT=I)ISK,DISP=  (OLD, DELETE) 

//         DD  DSN=USFR.r'3503.LMOD(nSP),DISP=S!iR 

//FTCJ0V001  DD     DSK=U5ER.r3503.TEOT,UNIT=DISK,VOL=SER=UIPUBl, 

//  SPACE=(1024, (25, 10), RLSE),DISr=(NEW, DELETE), 

//  BC3=(KECFI^VBS,LRECL=1020,3LKSIZE=1024) 

//FT05F001  TO  * 

***        USER-SUPPLIED  DATA  CARDS 

/* 
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APPENDIX  D 
MODEL  ERROR  MESSAGES 
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The  descriptions  of  the  various  errors  and  possible  errors 
detected  by  MAP  are  listed  below  along  with  the  associated  message  numbers. 
Warning  messages  are  identified  by  a  W  in  the  first  column.   This  character 
is  not  printed  with  the  message.   Blank  error  descriptions  indicate  message 
numbers  which  are  not  used. 
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The  descriptions  of  the  errors  and  possible  errors  detected  by 
MODEL  are  listed  below  along  with  the  associated  message  numbers.   Warning 
messages  are  preceded  by  a  V  which  is  not  printed  when  the  warning  is  is- 
sued. J'.lanl  nessa^es  indicate  Message  numbers  which  are  rot  used. 


1  ERROR  IN  MODEL.  ANALYSIS  ABORTED 

2  INPUT  area  overflow;,  analysis  aborted 

3  MODEL  NAME  HISSING.  ANALYSIS  ABORTED 

4  ELEMENT  IF  A  KUB-FLEMEHT  01'  ITSELF.  ANALYSIS  ABORTED 
5 

6  MEOFATION  IN  MUTUALLY  IITDEPENDENT  VARIABLES  ONLY.  MAY  BE  INCONSISTENCY 

7  NSYSTEM  MAY  BE  SINGULAR.  NUMBER  OF  EQUATIONS  -•  ■  NUMBER  OF   VARIABLES 


10  MIE>PROPEP  UNIT  'RTMBER.  OUTPUT  SENT  TO  UNIT  6 

11  JMODEL  TAMP  SHORTENED  TO  8  CHARACTERS 

12  TYPE  INSTRUCTION  IGNORED.  TYPE  NAME  MISSING 

13  0TEE/1INAL  TYPE  NAME  SHORTENED  TO  P  CHARACTERS 
14 

15 

16  TERMINAL  TYPE  HAS  NO  VARIABLES 

17  FUNCTION  DEFINITION  IGNORED.  TOO  MtANY  FUNCTIONS  DEFINED 

18  FUNCTION  DEFINITION  IGNORED.  FUNCTION  NAMF  MISSING 
VI  E'FUNCTION  NA*  -t  SHORTENED  TO  €    CTIAPACTT'P!' 

20  "UNCTION  DEFINITION  IGNORED.  IMPROPER  ARGUMENT  COUNT 

21  FUNCTION  DEFINITION  IGNORED.  NO  ARGUMENTS 

22  TABLF  FUNCTION  DEFINITION  IGNORED.  TABLE  rtUMBER  :r0T  POSITIVE-  INTEGER 

23  TABLE  FUNCTION  DEFINITION  IGNORED.  TABLE  NUMBER  USED  PREVIOUSLY 

24  ^'independent  variable  name  seortenfd  to  3  characters 

25  improper  dimension.  dimension  set  to  1 

26  element  name  missing 

27  './element  name  shortened  to  r  characters 

28  UMDEFINEE  INSTRUCTION  IGNORED 

29  ' 'SUB-ELEMENT  NAM!  SHORTENED  TO  3  CHARACTERS 

30  TERMINAL  DECLARATION  IGNORED,  D1PROPER  TERMINAL  ID  NUMEER(S) 

31  '^TERMINAL  ID  HUNGERS  SPECIFIED  IN  I'RONG  ORDER.  ORDER  REVERSED 

32  '.TERMINAL  TYPE  NAME  SHORTENED  TO  3  CIIARACTERS 

33  TERMINAL  TYPE  NOT  ASSIGNED.  TERMINAL  TYPE  NAME  UNDEFINED 

34  EXTERNAL  TERMINAL  DECLARATION  IGNORED.  IMPROPER  TERMINAL  IE  NUMBEE(S) 

35  EXTERNAL  TERMINAL  DECLARATION  IGNORED.  TERMINAL  NOT  DECLARED 

36  CONNECTION  TO  SUB-ELEMENT  IGNORED.  IMPROPER  TERMINAL  ID  NUMEER(S) 

37  CONNECTION  10  SUB-ELEMFNT  IGNORED.  TERMINAL  NOT  DECLARED 
32  CONNECTIO?]  IGNORED.  IMPROPER  TERMINAL  ID  NUM3EP(8) 

32   CON^LCTION  IGNORED.  TERMINAL(S)  NOT  DECLARED 

40  EQUATION  IGNORED.  BUILT  IN  FUNCTION  ARGUMENT  3EF0RE  ?  lr    :rOT  SCALAR 

41  UNRECOGNIZABLE  CHARACTEF  LEFORF  ?  IGNORED 
^2   EQUATION  IGNORED.  OPERAND  MISSINC  BEFORE  ? 
A3   EQUATION  IGNORED.  OPERATOR  MISSINC  BEFORE  ? 

44  'NA'P;  SHORTENED  TO  3  CHARACTERS  BEFORE  ? 

45  EQUATION  IGNORED.  NUMERICAL  STRING  EEFORE  ?  Tc  TOO  LONG 

46  EQUATION  IGNORED.  UNDEFINED  VARIABLE  "VIP  BEFORE  ? 

47  EQUATION  IGNORED.  UNDEFINED  TFRMINAL  ID  NUMBER  BEFORE  ? 

48  EQUATION  IGNORED.  THRONG  PORN  FOR  TEFMINAL  in  NUMBER  BEFORE  ? 

49  ROTATION  IGNORED.  REFERENCF  Tn  UNTYPED  TERMINAL  BEFORE  ? 
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50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
SO 
31 
32 
33 
34 
85 
36 
37 
38 
89 
90 
91 
?2 


PC 

»/ 
96 
97 
98 

99 


EQUATION  IGNORED. 
EQUATION  IGNORED. 
EQUATION  IGNORED. 
EQUATION  IGNORED. 
EQUATION  IGNORED. 
EQUATION  IGNORED . 


UNDEFINED  TERMINAL  VARIABLE  NAME  BEFORE  ? 

STRIP  TERMINAL  VARIABLE  REFERENCE  IS  NOT  IN  FUNCTION 

TOO  MANY  FUNCTION  ARGUMENTS  BEFORE  ? 

TOO  FD'T  FUNCTION  ARGUMENTS  BEFORE  ? 

INCOMPLETE  FUNCTION  REFERENCE  BEFORE  ? 


EQUATION 

EQUATION 
EQUATION 
EQUATION 
EQUATION 
EQUATION 
EQUATION 
EQUATION 


IGNORED . 
IGNORED . 
IGNORED. 
IGNORED. 

IGNORED. 
IGNORED. 

IGNORED. 
IGNORED . 


MISPLACED 
UNMATCHED 
UNMATCHED 
MISPLACED 
=  MISSING 


( 


BEFORE  ? 
(S)  BEFORE 
BEFORE  ? 
BEFORE  ? 


BEFORE  ? 


EXTRA  =  BEFORE  ? 

IMPROPER  FORM  FOR  PARAMETER  ASSIGNMENT 

INTEGER  DIMENSION  EXPECTED  BEFORE  ? 


UNDEFINED  PSEUDO  TERMINAL  ID  NUMBER  BEFORE  ? 

IF-TIIEN-ELSE  IGNORED.  OPERATOR-OPERAND  TYPE  DISAGREEMENT  BEFORE  ? 

EQUATION  IGNORED.  ILLEGAL  USE  OF  |,&,<t  OP  >  INSIDE  FUNCTION 

IF-TKEN-ELSE  IGNORED.  IF  CLAUSE  IS  NOT  A  LOGICAL  EXPRESSION 

ELSE  CLAUSE (S)  IGNORED.  NOT  PRECEEDED  BY  IF-THEN 

IF-TEEN-ELSE  IGNORED.  MISSING  THEN  CLAUSE 

EQUATION  IGNORED.  UNMATCHED  (  (S)  IN  ARGUMENT  BEFORE  ? 

EQUATION  IGNORED.  UNDEFINED  TABLE  FUNCTION  NUMBER  BEFORE  ? 

EQUATION  IGNORED.  COMMA  MUST  FOLLOW  TABLE  FUNCTION  NUMBER 

INITIAL  VALUE  ASSIGNMENT  IC>TORED.  IMPROPEP  FORM 

EQUATION  IGNORED.  PRECEEDING  EXPRESSION  UNDEFINED  -  IMPROPER  DIMENSIONS 

EOLATION  IGNORED.  NO  TERMINALS  CONNECTED  TO  STRIP  TERMINAL 
■TERMINAL  IS  DOUBLY  DEFINED 

WVARIABLE  OR  PARAMETER  NAME  SHORTENED  TO  8  CHARACTERS 
DECLARATION  OF  INDEPENDENT  VARIAELF  IS  NOT  NECCESSAEY 


TERMINAL  MAS  NOT  BEEN  ASSIGNED  A  TYPE 

LOCAL  CONNECTION  IGNORED.  TERMINAL  TYPE  MISMATCH 

EXTERNAL- INTERNAL  TERMINAL  TYPE  MISMATCH 

EXTERNAL  TERMINAL  IN  OUTER  ELEMENT  REDECLARED  AS 

EXTERNAL  TERMINAL  REDECLARED  AS  A  LOCAL.  TOO  FEN 

EXTRA  CONNECTION (S)  TO  ELEMENT  IGNORED 

REFERENCE  TO  UNDEFINED  SEE-ELEMENT  IGNORED 
DERIVATIVE  OF  CONSTANT  VARIABLE  REPLACED  BY  0 
^-^EQUIVALENCE  OF  WO  INDEPENDENT  VARIABLES  IGNORED 
"./EQUIVALENCE  OF  INDEPENDENT  VARIABLE  AND  CONSTANT  IGNORED 

EXTERNAL  CONNECTION  HAS  UNMATCHED  STRIP  TERMINAL 

EXTERNAL  STRIP  TERMINAL  NOT  ASSIGNED  A  TYPE 

CONNECTION  OF  TWO  STRIP  TERMINALS  IGNORED 

CONNECTION  TO  EXTERNAL  STRIP  TERMINAL  IGNORED 

" "-''  :"-  is-::   ignored,  else  clausi  missing  after 

'.'INITIAL  VALUE  ASSIGNMENT  FOR  AN  INDEPENDENT  VARIABLE  IGNORED 
INITIAL  VALUE  UNKNO'/N  AT  TIME-TSTART.  ASSIGNMENT  IGNORED 

'.INITIALIZED  VARIABLE  APPEARS  IN  NO  EQUATIONS 
IMPROPER  DIMENSIONS.  VARIABLE  OR  PARAMETER  REDECLARED  AS  SCALAR 
EOLATION  IGNORED.  CONTAINS  MORI  TNAr-r  6  NESTED  NON-SCALAR  FUNCTIONS 


A  LOCAL 

CONNECTIONS  TO  ELEMENT 
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